Business Objects - Contenants ou fonctionnels? [fermé]

https://stackoverflow.com/questions/1794274

22-09-2019
|

Question

Là où je travaille, nous sommes revenus en arrière à ce sujet un certain nombre de fois et sommes à la recherche d'un chèque de santé mentale. Voici la question:. Si Business Objects être des conteneurs de données (plus comme DTO), ou si elles contiennent également une logique qui peut effectuer certaines fonctionnalités sur cet objet

Exemple - Prenez un objet client, il contient probablement des propriétés communes (Nom, identification, etc.), cet objet devrait également inclure client fonctions (Enregistrer, Calc, etc.)

Une ligne de raisonnement dit séparer l'objet de la fonctionnalité (principale unique de responsabilité) et mettre la fonctionnalité dans une couche logique métier ou un objet.

L'autre raisonnement dit, non, si j'ai un objet client, je veux juste appeler Customer.Save et faire avec elle. Pourquoi dois-je savoir sur la façon de sauver un client si je consomme l'objet?

Nos deux derniers projets ont eu les objets séparés de la fonctionnalité, mais le débat a été soulevé à nouveau sur un nouveau projet. Ce qui est plus logique?

EDIT

Ces résultats sont très semblables à nos débats. Un vote d'un côté ou l'autre change complètement la direction. Est-ce que quelqu'un d'autre veut ajouter leurs 2 cents?

EDIT

Eventhough l'échantillonnage de réponse est faible, il semble que la majorité croit que la fonctionnalité dans un objet métier est acceptable tant qu'il est simple, mais la persistance est le mieux placé dans une catégorie distincte / couche. Nous allons essayer ce. Merci pour les commentaires de chacun ...

La solution

Les objets sont l'état et le comportement ensemble. Si un objet a un comportement sensible (par exemple, le calcul de l'âge pour une personne à partir de leur date de naissance, ou une taxe totale pour une facture), par tous les moyens ajouter. Les objets métier qui sont rien de plus que DTO sont appelés un « modèle de domaine anémique. » Je ne pense pas que ce soit une exigence de conception.

La persistance est un type particulier de comportement. Ce que je vous appelle « sensible » est le comportement des entreprises. Un objet métier pas besoin de savoir qu'il est persistant. Je dirais qu'un OAC peut garder la persistance séparée du comportement des entreprises. Je ne mets pas « sauver » dans la catégorie « sensible ».

Autres conseils

Les objets métier CAN ont fonctionnalité d'affaires .

La persistance est pas une fonctionnalité d'entreprise , mais la mise en œuvre technique.

Longue histoire courte:

Enregistrer / Mise à jour / Supprimer / Trouver etc -. Tenir à l'écart des objets métier dans une couche de persistance
CalculateSalary, ApplyDiscount etc sont des méthodes commerciales connexes et peuvent être:
1. méthodes des objets métier (si BO est une représentation autonome de l'entité) ou;
2. services distincts mise en œuvre de fonctionnalité particulière (si BOs agissent plus comme DTO).

En ce qui concerne le point 2.
Je dois mentionner que l'approche 2.1 tend à rendre le bos trop lourd et violation SRP . Alors que plus d'entretien 2.2 introduit complexité .

Je habituellement équilibre entre 2.1 et 2.2 pour que je mets des choses insignifiantes liées aux données dans Business Objects et créer des services pour un peu de scenarious plus complexe (s'il y a plus de 4 lignes de code - rendre un service).

Cela déplace le paradigme de Business Objects pour plus de transfert de données des objets à la place.

Mais tout cela rend plus facile projet de développer, tester et maintenir.

La réponse est la même quelle que soit la plate-forme ou la langue. La clé de cette question est de savoir si un objet doit pouvoir être autonome ou s'il est préférable pour tout comportement donné à répartir entre les objets avec plus responsabilité concentrée .

Pour chaque classe la réponse pourrait être différente. Nous nous retrouvons avec un spectre le long de laquelle nous pouvons placer les classes basées sur la Densité de responsabilité .

                          (Level of responsibility for behavior)
         Autonomy - - - - - - - - - - - - - - - - - - - Dependence  
      High
  C      -   <<GOD object>>                            <<Spaghetti code>>
  l      -
  a      -  
  s      -                                      
  s      -                 
         -                        
  s      -  
  i      -  
  z      -
  e      -  <<Template>>                                <<Framework>>
       low

Disons que vous faveur de laisser la classe accomplir toutes les comportements lui-même, ou autant que vous le pouvez. À partir du côté gauche de ce graphique, lorsque vous faites votre classe plus autonome, la taille de la classe se développera à moins que vous refactoring de façon continue pour le rendre plus générique. Cela conduit à un modèle . Si refactorisation est fait, le temdency est pour la classe pour devenir plus « comme Dieu » parce que s'il y a un comportement dont il a besoin, il a une méthode pour cela. Le nombre de champs et méthodes croître et bientôt devenir à la fois ingérable et inévitable. Étant donné que la classe fait déjà beaucoup, codeurs préfèrent ajouter à la monstruosité que d'essayer de reconstituer le démonter et de couper le nœud gordien.

Le côté droit du graphique a des classes qui dépendent d'autres classes dans une large mesure. Si le niveau de dépendance est élevé, mais la classe individuelle est petite, qui est un signe d'un cadre ; chaque classe ne fait pas beaucoup et exige beaucoup de classes dépendantes pour accomplir une fonction. D'autre part, une classe fortement dépendante qui a également une grande quantité de code est un signe que la classe est pleine de Spaghetti .

La clé de cette question est de savoir où vous vous sentez plus à l'aise sur le graphique. En tout état de cause, les cours individuels finissent par diffusion sur le graphique à moins qu'un principe d'organisation est appliqué, ce qui est la façon dont vous pouvez obtenir les résultats de Modèle ou Cadre .

Après avoir écrit tout cela, je dirais qu'il ya une corrélation entre la taille de la classe et le degré d'organisation. Robert C. Martin (ou "Oncle Bob") couvre-sol similaire avec les dépendances de package dans son article très complet sur Principes de conception et modèles de conception . JDepend est une mise en œuvre des idées derrière le graphique à la page 26 et complète outils d'analyse statique comme et href="http://pmd.sourceforge.net/" rel="nofollow noreferrer"> PMD .

Je pense qu'il est plus logique pour les objets métier de savoir comment « gérer » eux-mêmes, alors devoir mettre ailleurs ce fardeau dans le système. Dans votre exemple, l'endroit le plus logique de traiter comment les données des clients « sauver » serait, pour moi, dans l'objet client.

Cela peut être parce que je considère que la base de données pour être le « conteneur de données », donc je suis en faveur des « objets métier » étant le niveau supérieur qui protège le conteneur de données d'un accès direct et met en application des « règles d'affaires » standard sur comment ces données est accessible / manipulé.

Nous avons utilisé le cadre de l'AAPC Rocky Lhotka pendant des années et aime la façon dont il est conçu. Dans ce cadre toutes les fonctionnalités est contenue dans les objets. Alors que je peux voir la valeur de separting la logique, je ne pense pas que nous allons se détourner de cette philosophie quand bientôt.

Les objets métier doivent être sur l'encapsulation des données et les comportements associés de l'entité commerciale modélisé par cet objet. Pensez-y comme ceci: l'un des grands principes de la programmation orientée objet est encapsulant les données et les comportements associés à ces données.

La persistance est pas un comportement de l'objet modélisé. Je trouve le développement progresse plus facilement si les objets d'affaires sont la persistance ignornant. Développer un nouveau code et les tests unitaires nouveau code se produisent plus rapidement et plus lisse si les objets d'affaires ne sont pas spécifiquement liés à la plomberie sous-jacente. Ceci est parce que je peux se moquer de ces aspects et d'oublier d'avoir à passer à travers des cerceaux pour se rendre à la base de données, etc. Mes tests unitaires exécuter plus rapidement (un énorme plus si vous avez des milliers de tests automatisés qui fonctionnent avec chaque génération) et moi aura moins de stress parce que je ne vais pas faire des tests à défaut en raison de problèmes de connexion de base de données (si vous travaillez en mode hors connexion ou à distance et ne peut pas accéder à votre base de données toujours souvent et oh, en passant, ces aspects (base de données de connectivité, etc.) devraient être testé ailleurs!).

L'autre raisonnement dit, non, si j'ai un objet client, je veux juste appeler Customer.Save et faire avec elle. Pourquoi dois-je savoir sur la façon de sauver un client si je consomme l'objet?

Sachant que Customer a une méthode Save est déjà savoir comment enregistrer un objet client. Vous ne l'avez pas évité le problème en intégrant cette logique dans votre objet métier. Au lieu de cela, vous avez fait votre base de code Couplé plus étroitement et donc plus difficiles à maintenir et à tester. Pousser la responsabilité de la persistance de l'objet à quelqu'un d'autre.

Les objets métier, comme ils sont nommés, devraient Coutain évidemment leur propre logique métier, la dynamique de la logique métier entre le domaine étant dans la couche de service.

D'un autre côté, la BO pourrait être une composition contenant de données (DTO?) Et les méthodes; ce qui signifie BO sont pur fonctionnelle? Cela pourrait éviter toutes les conversions entre BO et DTO.

Dans une architecture MVC,

Peut-on dire que le modèle contient des objets d'affaires.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow