ASP.NET MVC Model & Business Objects

Question

Je cherche des conseils sur la façon d'incorporer des règles de gestion dans une application mvc asp.net et comment elles se rapportent au modèle. D'abord un peu d'arrière-plan afin que nous sachions quel genre de solutions sont relatives à cette question. Au travail, nous utilisons WinForms, MVP, BusinessObjects, DataAccessObjects et DataTransferObjects. Les limites des couches utilisent des objets DTO pour envoyer des paramètres aux méthodes et en tant que types de retour, ou renvoyer des types de liste.

Actuellement, nous ajoutons une couche de façade pour traduire les objets DTO en objets de domaine pour que l'interface utilisateur fonctionne, car l'architecte n'aime pas l'utilisation actuelle des DTO dans PresentationLayer. Je suis à l'aise avec tout cela en théorie, mis à part le fait qu'il soit pratique ou non. Je fais un site web pour le plaisir, mais pour des considérations, disons que ça sert la même quantité de trafic que SO, quelque chose comme 60 000 visites par mois dernier que j'ai entendu. Je suis à l'aise avec la mécanique des contrôleurs et les vues, et comment le modèle s'intègre avec les deux.

J'utilise NerdDinner comme exemple pour la construction du site et je suis l'implémentation du modèle Repository dans les exemples. Ce que je ne comprends pas, c'est comment intégrer des objets métier dans le mix. J'entends les gens parler de LINQ comme DataAccessLayer/DataAccessObjects. Si je force toutes mes demandes à travers les objets de gestion comme je suis habitué, j'ai introduit des dépendances étranges. Mon interface utilisateur et mon BO doivent tous deux connaître mon DAO. Ce qui aurait du sens serait d'utiliser les classes LINQ comme une vraie couche DAO, de la cacher derrière la BO et de transformer la BO entre les objets POCO et LINQ. Ma seule préoccupation ici est que je vais bien relier mon interface utilisateur aux classes LINQ, et que je n'ai pas vraiment besoin de tout le travail supplémentaire, je suis content d'une approche légère et légère comme dans NerdDinner.

Donc ce que j'ai essentiellement, c'est le Repository qui est instancié dans les contrôleurs qui prennent et retournent les objets LINQ. Mes objets métier ont des méthodes statiques qui prennent simplement des classes LINQ et effectuent des calculs, par exemple, appliquent une certaine taxe d'état%, ou w/e. Comme beaucoup de ces calculs doivent être effectués à travers les résultats du dépôt, je pense à les combiner en une zone centrale, comme une couche de façade, mais qui ne fait que se transformer contre les données et ne pas se traduire par d'autres ensembles d'objets (DomainObjects < -> DTO).

Devrais-je faire cela, ou devrais-je dire que ces méthodes commerciales font vraiment partie de mon modèle et qu'elles devraient être dans les méthodes de référentiel qui renvoient les objets?

Answer 1

D'un point de vue design, je le conçois comme ça. Bien sûr, le nom est juste dans le but de ce poste, vous n'avez pas à nommer votre DAL et BLL ..Repository et ..Service.

Avoir des dépôts (ou un répertoire) où vos accès/requêtes de données devraient se produire. Idéalement, il ne devrait contenir que des requêtes (compilées ou non). J'ai personnellement un référentiel pour chaque type de données pour aider à garder les requêtes séparées.

La couche suivante devrait être votre couche de gestion que j'aime appeler les services. Ces classes sont responsables de toute la logique concernant la validation, les étapes de préparation et tout ce qui doit être fait pour fournir au consommateur du service l'information dont il a besoin. Comme avec une application ASP.NET MVC, mes services renvoient des modèles de vue qui sont ensuite transmis directement dans des vues fortement typées.Avec mes services, je les regroupe généralement logiquement au lieu d'un pour chaque type de données.

Ceci est une excellente conception car elle maintient votre code d'accès aux données et le code de présentation agréable et mince et la majeure partie de la logique où les choses peuvent mal se passer est dans votre couche de service.