couche de gestion avec plusieurs objets avec toutes les propriétés remplies à partir de la base de données ou un objet avec seulement un sous-ensemble rempli

Question

Je construis un système de taille moyenne et je suis confronté à un problème auquel certains d'entre vous ont probablement déjà été confrontés.Dans ma couche métier, je renvoie des objets métier avec un sous-ensemble de propriétés importantes pour cette méthode métier. Je suis inquiet car je peux me retrouver avec trop d'objets avec des noms dénués de sens ou un seul dans lequel seul un sous-ensemble de propriétés est renseigné. méthode.Permettez-moi de donner un exemple.

Cas 1

Par exemple, un utilisateur appartient à une ville, qui à son tour appartient à un État et à un pays, User, City, State et Country il y a des tables dans ma base de données avec beaucoup de champs, mais je veux une liste d'utilisateurs avec une liste de commandes, je crée donc un objet métier appelé par exemple UserWithOthers avec seulement les propriétés importantes (UserId, UserName, CityName, StateName, CountryName, List<Order>) et mon DAL récupère uniquement ces champs de la base de données.

Cas 2

Je souhaite renvoyer maintenant un utilisateur avec le montant des commandes, je termine avec les champs suivants dans mon objet métier (UserId, UserName, CityName, StateName, CountryName, OrdersCount) et la classe pourrait s'appeler par exemple UserWithOrderCount

J'ai réfléchi à quelques options :

1. Créez deux classes métier et remplissez-les séparément dans chaque méthode DAL (ces objets sont simples mais considérez que cette méthode peut avoir une requête de sélection complexe qui doit être encapsulée pour être réutilisée afin que le modèle de référentiel ne s'adapte pas bien ici, du moins je pense que ).
2. Créer un seul objet User avec toutes les propriétés (UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>) et ne remplissez qu'un sous-ensemble dans chaque méthode DAL, mais cela implique un couplage sémantique lorsque vous utilisez une méthode, car vous devez savoir quel sous-ensemble de champs est rempli à partir de la base de données, et le couplage sémantique est le pire de tous les couplages.
3. L'option 1 ne fonctionne pas bien si j'en ai besoin plus tard dans une autre vue, les deux, List<Order> et OrdersCount propriétés.
4. Considérez maintenant que si vous utilisez les bonnes pratiques ASP.NET MVC, cela indique que vous avez besoin d'un ViewModel pour passer à la vue, j'ai pensé à renvoyer les ViewModels de ma couche Businnes, mais je ne pense pas que ce soit une bonne idée, j'ai l'impression que je suis violer quelque chose, et ce n'est pas non plus possible car ma couche métier se trouve dans un autre assembly et non dans l'application Web.
5. Je ne veux pas écrire la même requête Linq encore et encore, mais si vous utilisez NHibernate ou EFCodeFirst, c'est "comme" la première option, et je devrai créer des tonnes de petits objets métier.

Comment gérez-vous cette situation ?Je pense que c'est une décision de conception de haut niveau.

Answer 1

Tout d'abord, je suis tout à fait d'accord avec toi sur certaines choses à ne pas faire :

1. Ne remplissez pas partiellement les objets métier, car vous confiez alors la responsabilité de savoir quelles propriétés sont renseignées aux clients de la couche métier, ce qui est une très mauvaise pratique.

2. Ne renvoyez pas les ViewModels de votre couche métier ;votre couche métier est censée représenter les concepts métier du domaine de votre application, et un ViewModel est un objet de données qui contient les données nécessaires pour afficher une vue particulière d'une partie de ce domaine - les deux sont des choses très différentes et la couche métier doit ignorer complètement que ses objets métier sont utilisés dans n'importe quel type d'interface graphique.

Je suivrais votre première suggestion : créer un objet métier distinct pour représenter chaque concept commercial.J'utiliserais ensuite un ORM (comme EF ou NHibernate) pour remplir ces objets pour moi, avec des référentiels dédiés pour chaque groupe d'objets.J'utiliserais ensuite une couche d'application qui appelle les référentiels pour renvoyer tous les objets requis.à cette fin, votre référentiel peut inclure des méthodes qui renvoient les utilisateurs et les commandes joints lorsque vous savez que vous devez utiliser ces deux types ensemble.Cela vous permet de renvoyer un utilisateur avec toutes ses commandes dans une seule requête, tout en conservant des entités distinctes et significatives pour représenter les utilisateurs et les commandes.