What is the best practice for Enterprise level application architecture using MVC5?

问题

I was wondering what is the best practice for enterprise level architecture based on MVC5. I mean selection between multiple layer or multiple project in one solution? and or maybe more than one solution? any good example project?

回答1:

Since my question has been visited a lot in the last year and there is no solid answer as I am aware of that, I decided to provide a comprehensive answer as much as possible. This answer is based on some actual projects experience and with few expert consultations:

First of all, it is important to note that in software design process, there is nothing like solid right and wrong. As long as an approach works for your project and fits well, it is right and if it doesn’t, it is wrong. There are no rigid principals in software design. There are Project needs and specifications. But generally, it has been accepted using Design Patterns and Principles makes project more robust, reliable and easy to maintain and make your code loosely coupled and highly cohesive.
The whole story of Software Design and Architecture is about how you could manage your project easily and how you could maintain your future changes. Think about which approach gives you best answer on them. That will be the best for you. Don't think too much about Professionalism! .Your project grows by time and gets more mature. So just think about your project!
As a first step and for Enterprise level application architecture, always try to follow Separation of Concerns or SoC. It means you should have different tiers for different layers of your project. It is highly recommended to use different project in your solution for Data Access Layer, Domain Entities, Business Layerand Presentation Layer. In MVC5 project, it is better to use Class Library Project for Data Access Layer, Domain Entities, Business Layer and a MVC project for Presentation Layer.
Data Access Layer is the project that faces to database and database interactions. You could have all your Entity Framework or similar entities in this project. Having separated layer for database layer means in the case of changing your project data warehouse, the only thing you need to change is changing this project and some minor changes on your Business Layer. All other projects in your solution remain intact. So you could easily move from MS Sql to Oracle or from Entity Framework to NHibernate.
Domain Entities is the project I use to define all my solution level interfaces, classes, enums and variables. This project keeps integrity throughout my solution on my classes and my methods. My all classes in whole solution are inherited from interfaces in this project. So I have one place to change my classes or global variables and it means Easy to Maintain for future in my solution and easy to understand for newly joined developers to the project.
Business Layer is the place I put my all business logic including Business Entities and Business Services. The whole idea about this layer is having one place to keep your all business methods and interactions. All calculations, object modification and all logic about data including saving, retrieving, changing and so on should happen in this section. By having this layer in your project, you could have different consumers at the same time, for example one native MVC and one Web API layer. Or you could provide different feeding based on different business services consumers specifications. It is highly recommended to avoid putting any business logic into controller section of MVC layer. Having any business logic inside controllers means you using your presentation layer as business logic layer and it violates Separation of Concerns. Then it won’t be easy to change from one presentationlayer to other or having different type of consumers for your solution. It is better to keep controller section in MVC as slim as possible. The controllers should only have logic and methods directly related to View Models. For more information about View Models refer to section 7. One thing to remember, It is better to have different Business Services classes based on your solution objects or Business Entities.
Presentation Layer in MVC solution will be an MVC project. But solution could have other type or more than one Presentation Layers for different consumers or technology. For example you could have one MVC layer and one Web API in one solution. Generally Use Presentation Layer to keep all presentation logic in it. Presentation logic shouldn’t have anything related to business logic or data logic. So question is what is Presentation logic? Presentation logic is logic related to view models. View models are objects customized for views or pages. In most cases, business objects are not suitable to use in views. On the other hand, presentation views usually need some validation logic or presentation logic, for example display name different than original object names. In these cases it is better keep presentation logic separated than business logic to make it easy to change presentation logic or business logic independently and even easy to switch presentation layer for different UI design or changing business logic for having more functionality without fear of any interruption with presentation logic. In the case of using MVC project as presentation layer for solution, all view models should be places in Models section of MVC project and all presentation logic should be placed in Controllers section of project.
The last thing to say is for every multi-tier solution, you need frameworks for object to object mapping, for example to convert your business entity to view model. There are some tools for this purposes like AutoMapper, BLToolkit, and EmitMapper.