Quelle est la meilleure pratique pour l'architecture d'application de niveau entreprise utilisant MVC5?

Question

Je me demandais quelle était la meilleure pratique pour une architecture de niveau entreprise basée sur MVC5. Je veux dire la sélection entre plusieurs couches ou plusieurs projets dans une seule solution? et ou peut-être plus d'une solution? un bon exemple de projet?

Hadee · Accepted Answer

Étant donné que ma question a été beaucoup visitée au cours de l'année dernière et qu'il n'y a pas de réponse solide à ma connaissance, j'ai décidé de fournir une réponse complète autant que possible. Cette réponse est basée sur une expérience réelle de projets et avec peu de consultations d'experts:

Tout d'abord, il est important de noter que dans le processus de conception de logiciels, il n'y a rien de tel que le bien et le mal. Tant qu’une approche fonctionne pour votre projet et s’adapte bien, c’est right et si ce n’est pas le cas, c’est wrong. Il n'y a pas de principes rigides dans la conception de logiciels. Il y a Project needs and specifications. Mais généralement, il a été accepté en utilisant Design Patterns and Principles rend le projet plus robust, reliable et easy to maintain et faites votre code loosely coupled and highly cohesive.
Toute l'histoire de Software Design and Architecture explique comment gérer facilement votre projet et comment conserver vos modifications futures. Réfléchissez à l'approche qui vous donne la meilleure réponse. Ce sera le meilleur pour vous. Ne pensez pas trop à Professionalism! Votre projet grandit avec le temps et devient plus mature. Alors pensez à votre projet!
Dans un premier temps et pour l'architecture d'application au niveau de l'entreprise, essayez toujours de suivre Separation of Concerns ou SoC. Cela signifie que vous devez avoir différents niveaux pour différentes couches de votre projet. Il est fortement recommandé d'utiliser différents projet dans votre solution pour Data Access Layer, Domain Entities, Business Layeret Presentation Layer. Dans le projet MVC5, il est préférable d'utiliser Class Library Project pour Data Access Layer, Domain Entities, Business Layer et un projet MVC pour Presentation Layer.
Data Access Layer est le projet qui fait face à la base de données et aux interactions de base de données. Vous pourriez avoir tout votre Entity Framework ou des entités similaires dans ce projet. La séparation de la couche pour la couche de base de données signifie que dans le cas de la modification de votre entrepôt de données de projet, la seule chose que vous devez changer est de modifier ce projet et quelques modifications mineures sur votre Business Layer. Tous les autres projets de votre solution restent intacts. Vous pouvez donc facilement passer de MS SQL à Oracle ou de Entity Framework à NHibernate.
Domain Entities est le projet que j'utilise pour définir toutes mes interfaces, classes, énumérations et variables au niveau de la solution. Ce projet garde l'intégrité tout au long de ma solution sur mes cours et mes méthodes. Toutes mes classes dans la solution entière sont héritées des interfaces de ce projet. J'ai donc n endroit pour changer mes classes ou variables globales et cela signifie Easy to Maintain pour l'avenir dans ma solution et facile à comprendre pour les développeurs nouvellement joints au projet.
Business Layer est l'endroit où je mets toute ma logique métier, y compris Business Entities et Business Services. L'idée générale de cette couche est d'avoir un seul endroit pour conserver toutes vos méthodes et interactions commerciales. Tous les calculs, la modification d'objet et toute la logique concernant les données, y compris l'enregistrement, la récupération, la modification, etc., doivent se produire dans cette section. En ayant cette couche dans votre projet, vous pourriez avoir différents consommateurs en même temps, par exemple un MVC natif et un Web API couche. Ou vous pouvez fournir une alimentation différente en fonction des spécifications des consommateurs de différents services aux entreprises. Il est fortement recommandé d'éviter de placer une logique métier dans la section contrôleur de la couche MVC. La présence d'une logique métier dans les contrôleurs signifie que vous utilisez votre couche de présentation comme couche logique métier et qu'elle viole Separation of Concerns. Ensuite, il ne sera pas facile de passer d'une couche de présentation à une autre ou d'avoir différents types de consommateurs pour votre solution. Il est préférable de garder la section du contrôleur dans MVC aussi mince que possible. Les contrôleurs ne doivent avoir qu'une logique et des méthodes directement liées à View Models. Pour plus d'informations sur View Models se référer à la section 7. Une chose à retenir, il vaut mieux avoir différents Business Services classes basées sur vos objets de solution ou Business Entities.
Presentation Layer dans la solution MVC sera un projet MVC. Mais la solution peut avoir un autre type ou plusieurs couches de présentation pour différents consommateurs ou technologies. Par exemple, vous pouvez avoir une couche MVC et une Web API dans une solution. Utilisez généralement le calque de présentation pour y conserver toute la logique de présentation. La logique de présentation ne doit pas avoir de lien avec la logique métier ou la logique des données. La question est donc de savoir ce qui est Presentation logic? Presentation logic est une logique liée aux modèles de vue. Les modèles de vue sont des objets personnalisés pour les vues ou les pages. Dans la plupart des cas, les objets métier ne peuvent pas être utilisés dans les vues. D'un autre côté, les vues de présentation nécessitent généralement une logique de validation ou une logique de présentation, par exemple un nom d'affichage différent des noms d'objets d'origine. Dans ces cas, il est préférable de séparer la logique de présentation que la logique métier pour faciliter la modification de la logique de présentation ou de la logique métier indépendamment et même de changer facilement de couche de présentation pour une conception d'interface utilisateur différente ou de changer la logique métier pour avoir plus de fonctionnalités sans crainte d'interruption avec logique de présentation. Dans le cas de l'utilisation du projet MVC comme couche de présentation pour la solution, tous les modèles de vue doivent être placés dans la section Models du projet MVC et toute la logique de présentation doit être placée dans la section Controllers du projet.
La dernière chose à dire est que pour chaque solution à plusieurs niveaux, vous avez besoin de cadres pour le mappage objet à objet, par exemple pour convertir votre entité commerciale en modèle d'affichage. Il existe des outils à cet effet comme AutoMapper, BLToolkit et EmitMapper.

Dernier mot: veuillez commenter et marquer question et mon answer pour le rendre meilleur!