Meilleure structure pour la solution ASP.NET MVC

Question

J'ai essayé de structurer mon dernier projet MVC d'envergure en suivant une approche basée sur les meilleures pratiques, mais je n'ai pas bien compris ce que je faisais. Il possède un projet Data, Business et Web (MVC), mais les contrôleurs contiennent la plus grande partie du code, la couche de données utilise NHibernate et quelques dépôts sont responsables de trop de choses, et la couche Business est une décharge pour tout ce qui n'appartient pas aux deux autres projets. Cela fonctionne, mais je pense qu'il aurait pu être mieux configuré - les principales choses que je ne suis pas satisfait sont les gros contrôleurs et les dépôts.

Je commence un nouveau projet qui pourrait devenir une taille décente, alors je passe un peu plus de temps à essayer de mettre mon design au premier plan. Après avoir lu un peu plus, j'essaie d'avoir un référentiel par agrégat-root, puis d'avoir un service dans la couche Business pour chaque contrôleur dans la couche de présentation. Mes espoirs initiaux étaient que la majeure partie du code irait dans les services et ceci couplé avec les dépôts plus petits garderait mes contrôleurs et ma couche de données minces. Jusqu'ici cependant, cela ne se produit pas. Tout ce que j'ai lu suggère que les modèles de vue ne doivent pas être renvoyés depuis la couche de gestion, et doivent être remplis dans la couche de présentation, donc pour le moment ma couche de service passe principalement des modèles de ma couche de données à couche de présentation qui fait ensuite ce dont elle a besoin pour préparer les modèles de vue. Donc, j'ai encore de gros contrôleurs, plus une mince couche de données et d'affaires.

Ma couche de présentation connaît également à la fois ma couche métier et celle de données, mais je pensais qu'une partie du but de cette séparation était de réduire le couplage.

Est-ce que j'ai tout faux? Devrais-je cesser d'essayer de suivre aveuglément ce que je lis sur Internet et simplement préparer des modèles de vue dans la couche de gestion afin que je puisse y déplacer la majeure partie de mon code? Devrais-je revenir à l'ASP classique? :)

Answer 1

Le principal guide que j'utilise lors de la configuration d'une structure de projet consiste à s'assurer que je peux ajouter des attributs operationcontract à la couche logique métier, puis l'héberger en tant que service wcf. Si je peux le faire, cela signifie que la couche logique métier a isolé ma couche de données et n'interagit avec son client qu'en passant des structures et des entités simples. le datalayer est complètement caché.

donc ma structure habituelle ressemble à:

Solution 
    Business.Contracts (interfaces for bll layer in here) 
    Business.Logic  (concrete implementations of contracts in here) 
    Business.Entities (Pocos that bll uses) 
    Data.Contracts  (interfaces for dal) 
    Data.Sql   (Concrete Sql implementation of contracts) 
    Common.Enums  (Enums needed by all projects) 
    FrontEnd   (Main mvc app) 

Ainsi, dans cette structure, mon projet ne jamais mvc traite de l'espace de noms d'affaires et l'espace de noms commun. Lorsque j'interagis avec les entités, j'ai tendance à utiliser mes propres modèles dans le projet mvc pour me permettre d'ajouter des annotations et des fonctionnalités spécifiques au front-end, puis je fournis des conversions implicites pour que ces modèles puissent être utilisés de manière interchangeable avec les entités commerciales.

HTH