使用 MVC5 的企业级应用程序架构的最佳实践是什么? [英] What is the best practice for Enterprise level application architecture using MVC5?

问题描述

我想知道基于 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?

推荐答案

由于我的问题在去年被访问了很多，而且我知道没有可靠的答案，我决定提供一个全面的答案尽可能.这个答案是基于一些实际项目经验，很少有专家咨询:

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:

1. 首先需要注意的是，在软件设计中过程中，没有什么比得上固是非.只要一个方法适用于您的项目并且非常适合，它是 right 并且如果不是，它是错误的.软件中没有严格的原则设计.有项目需求和规范.但一般来说，它已被接受使用设计模式和原则项目更健壮、可靠和易于维护并使您的代码松散耦合且高度内聚.
2. 软件设计和架构的整个故事是关于如何您可以轻松管理您的项目以及如何维护您的项目未来的变化.考虑哪种方法可以为您提供最佳答案他们.那将是最适合你的.不要想太多专业性！.您的项目随着时间的推移而增长并变得更加成熟.所以，想想你的项目吧！
3. 作为企业级应用架构的第一步，始终尝试遵循关注点分离或SoC.这意味着你项目的不同层应该有不同的层.它强烈建议在您的项目中使用不同的项目数据访问层、域实体、业务层和表示层的解决方案.在MVC5项目中，Data Access Layer、Domain Entities、Business Layer最好使用Class Library Project和 Presentation Layer 的 MVC 项目.
4. Data Access Layer 是面向数据库和数据库交互的项目.您可以在此项目中拥有所有 Entity Framework 或类似实体.数据库层分离层意味着在改变你的项目数据仓库的情况下，你唯一需要改变的就是改变这个项目和你的业务层的一些小改动.解决方案中的所有其他项目保持不变.因此，您可以轻松地从 MS Sql 迁移到 Oracle，或者从 Entity Framework 迁移到 NHibernate.
5. Domain Entities 是我用来定义所有解决方案的项目级别接口、类、枚举和变量.这个项目保持在我的课程和方法的整个解决方案中的完整性.我的整个解决方案中的所有类都是从这个接口继承的项目.所以我有一个地方可以改变我的课程或全局变量，这意味着 易于维护 以备将来在我的解决方案中使用并且易于新加入项目的开发人员理解.
6. Business Layer 是我放置所有业务逻辑的地方，包括商业实体和商业服务.整个想法关于这一层有一个地方来保存你的所有业务方法和相互作用.所有计算、对象修改和所有逻辑关于数据包括保存、检索、更改等应该发生在这一节.通过在你的项目中加入这一层，你可以同时拥有不同的消费者，例如一个原生 MVC 和一个 Web API 层.或者你可以提供不同的基于不同业务服务消费者的馈送规格.强烈建议避免放置任何业务逻辑进入 MVC 层的控制器部分.有任何控制器内的业务逻辑意味着您使用演示文稿层作为业务逻辑层，它违反了关注点分离.那么就不容易从一个表示层更改为另一个表示层或为您的不同类型的消费者解决方案.最好保持 MVC 中的控制器部分像可能的.控制器应该只有逻辑和方法与 View Models 直接相关.有关查看模型的更多信息参考 7 部分.要记住的一件事，最好是根据您的解决方案有不同的 Business Services 类对象或业务实体.
MVC 解决方案中的
7. Presentation Layer 将是一个 MVC 项目.但解决方案可以有其他类型或多个表示层针对不同的消费者或技术.例如你可以有一个 MVC 层和一个 Web API 在一个解决方案中.一般使用表示层将所有表示逻辑保存在其中.表示逻辑不应该有任何与业务逻辑相关的东西或数据逻辑.那么问题是什么是呈现逻辑?Presentation logic 是与视图模型相关的逻辑.查看模型是为视图或页面定制的对象.大多数情况下，业务对象不适合在视图中使用.另一方面，演示视图通常需要一些验证逻辑或呈现逻辑，例如与原始显示名称不同的显示名称对象名称.在这些情况下，最好保留演示逻辑与业务逻辑分离，以便于更改表示逻辑或业务逻辑独立，甚至易于切换用于不同 UI 设计或不断变化的业务的表示层无需担心任何中断即可拥有更多功能的逻辑与呈现逻辑.在使用MVC项目的情况下解决方案的表示层，所有视图模型都应该放在MVC 项目的 Models 部分和所有表示逻辑应该是放置在项目的 Controllers 部分.
8. 最后要说的是对于每个多层解决方案，您需要对象到对象映射的框架，例如转换您的业务实体查看模型.有一些工具可以做到这一点AutoMapper、BLToolkit 和 EmitMapper 等用途.

1. 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.
2. 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!
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.

<小时>

最后一句话:请评论并评分question 和我的answer 以使其更好！

---

Last word: please comment and score question and my answer to make it better!

这篇关于使用 MVC5 的企业级应用程序架构的最佳实践是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！