C'est une question que j'ai posée il y a quelque temps sur SO, mais elle pourrait être mieux discutée ici ...
Là où je travaille, nous avons fait plusieurs allers-retours sur ce sujet à plusieurs reprises et recherchons un bilan de santé mentale. Voici la question: les objets métier doivent-ils être des conteneurs de données (plus comme des DTO ) ou doivent-ils également contenir une logique pouvant exécuter certaines fonctionnalités sur cet objet.
Exemple - Prenez un objet client, il contient probablement des propriétés communes (Nom, Id, etc.), cet objet client doit-il également inclure des fonctions (Enregistrer, Calc, etc.)?
Un raisonnement dit de séparer l'objet de la fonctionnalité (principe de responsabilité unique) et de placer la fonctionnalité dans une couche ou un objet Business Logic.
L'autre raisonnement dit, non, si j'ai un objet client, je veux juste appeler Customer.Save et en finir. Pourquoi dois-je connaître une autre classe pour sauver un client si je consomme l'objet?
Nos deux derniers projets ont eu des objets séparés de la fonctionnalité, mais le débat a de nouveau été soulevé sur un nouveau projet.
Qu'est-ce qui a plus de sens et pourquoi ??