Aujourd'hui, je suis entré dans un débat animé avec un autre développeur de mon organisation sur où et comment ajouter des méthodes aux classes mappées de base de données. Nous utilisons sqlalchemy
, et une grande partie de la base de code existante dans nos modèles de base de données n'est guère plus qu'un sac de propriétés mappées avec un nom de classe, une traduction presque mécanique des tables de base de données en objets python.
Dans l'argument, ma position était que la valeur principale de l'utilisation d'un ORM était que vous pouvez attacher des comportements et des algorithmes de bas niveau aux classes mappées. Les modèles sont d'abord des classes et secondairement persistants (ils peuvent être persistants en utilisant xml dans un système de fichiers, vous n'avez pas besoin de vous en soucier). Son point de vue était que tout comportement est une "logique métier" et appartient nécessairement n'importe où sauf dans le modèle persistant, qui ne doit être utilisé que pour la persistance de la base de données.
Je ne pense qu'il ya une distinction entre ce qui est la logique métier, et doit être séparé, car il a un certain isolement par rapport au niveau inférieur de la façon qui soit mis en oeuvre, et la logique de domaine, que je crois est l'abstraction fournie par les classes de modèle discuté dans le paragraphe précédent, mais j'ai du mal à mettre le doigt sur ce que c'est. J'ai une meilleure idée de ce que pourrait être l'API (qui, dans notre cas, est HTTP "ReSTful"), en ce sens que les utilisateurs invoquent l'API avec ce qu'ils veulent faire , distinct de ce qu'ils sont autorisés à faire et comment cela se fait.
tl; dr: Quels types de choses peuvent ou devraient aller dans une méthode dans une classe mappée lors de l'utilisation d'un ORM, et ce qui devrait être laissé de côté, pour vivre dans une autre couche d'abstraction?