使用 MVC5 的企业级应用程序架构的最佳实践是什么？

Question

我想知道基于 MVC5 的企业级架构的最佳实践是什么。我的意思是在一个解决方案中选择多层或多个项目？或者可能不止一种解决方案？有什么好的示例项目吗？

Answer 1

由于我的问题在去年被多次访问，并且据我所知没有可靠的答案，因此我决定尽可能提供全面的答案。这个答案是基于一些实际的项目经验和很少的专家咨询：

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

---

最后一句话：请评论和评分question和我的answer，让它变得更好！

Answer 2

看看Contoso University。优秀的企业级应用示例。

Sample Web Application Demonstration