Architecture 使用MVC5的企业级应用程序体系结构的最佳实践是什么？

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

看看。企业级应用程序的优秀示例

---

由于我的问题在去年被多次访问，而且我知道没有确切的答案，所以我决定尽可能提供一个全面的答案。该答案基于一些实际项目经验，很少有专家咨询：

首先，重要的是要注意，在软件设计中 在这个过程中，并没有什么比是非更坚实的了。只要 这种方法适用于您的项目，并且非常适合，它是正确的 它没有，它是

错误的

。软件中没有严格的原则 设计。有

项目需求和规范

。但总的来说,， 它已被接受使用

设计模式和原则

makes 项目更具

稳健性

，

可靠性

和

易于维护

和制作 您的代码

松散耦合且高度内聚

软件设计和架构的整个故事是关于如何
您可以轻松管理您的项目以及如何维护
未来的变化。想想哪种方法能给你最好的答案
他们。那对你来说是最好的。不要想太多
专业化
。您的项目会随着时间的推移而增长，并变得更加成熟。
所以想想你的项目吧
作为企业级应用程序体系结构的第一步，
始终尝试遵循
关注点分离
或
SoC
。意思是你
对于项目的不同层，应该有不同的层。信息技术
强烈建议在您的应用程序中使用不同的项目
解决方案用于
数据访问层
，
域实体
，
业务层
和
表示层
。在MVC5项目中，对于
数据访问层
，
域实体
，
业务层
和
表示层
最好使用
类库项目
数据访问层
是面向数据库和数据库交互的项目。您可以在此项目中拥有所有的
实体框架
或类似实体。为数据库层设置单独的层意味着在更改项目数据仓库的情况下，您唯一需要更改的是更改此项目和业务层上的一些小更改。解决方案中的所有其他项目保持不变。因此，您可以轻松地从MS Sql移动到Oracle，或者从
实体框架
移动到
NHibernate
域实体
是我用来定义所有解决方案的项目
级别接口、类、枚举和变量。这个项目保持
完整性贯穿于我的类和方法的解决方案中。我的
整个解决方案中的所有类都继承自此解决方案中的接口
项目所以我有一个地方可以改变我的课程或全球课程
变量，这意味着在我的解决方案中易于维护
对于新加入项目的开发人员来说，这很容易理解
业务层
是我放置所有业务逻辑的地方，包括
业务实体
和
业务服务
。关于
这一层有一个地方保存您的所有业务方法和
互动。所有计算、对象修改和所有逻辑
关于数据，包括保存、检索、更改等
发生在这一部分。通过在项目中使用此层，您可以
可能同时有不同的消费者，例如一个
原生
MVC
和一个
webapi
层。或者你可以提供不同的
基于不同业务服务消费者的馈送
规格。强烈建议避免放置任何
将业务逻辑转换为MVC层的控制器部分。有
控制器内的业务逻辑意味着您使用您的演示文稿
层作为业务逻辑层，它违反了
关注点分离
。那么，从一个presentationlayer切换到另一个presentationlayer，或者为您的客户提供不同类型的客户，就不容易了
解决方案最好使MVC中的控制器部分尽可能薄
可能的控制器应仅具有逻辑和方法
与查看模型直接相关。有关查看模型的更多信息

请参阅章节

7

。有一件事要记住，那就是 根据您的解决方案拥有不同的

业务服务

类 对象或

业务实体

MVC解决方案中的表示层将是一个MVC项目。但是 解决方案可以有其他类型或多个表示层 针对不同的消费者或技术。例如，你可以 一个解决方案中有一个MVC层和一个

WebAPI

。普遍使用 表示层将所有表示逻辑保留在其中。 表示逻辑不应该与业务逻辑相关 或数据逻辑。所以问题是什么是

表示逻辑

？

表示逻辑

是与视图模型相关的逻辑。视图模型 是为视图或页面自定义的对象。在大多数情况下，商业 对象不适合在视图中使用。另一方面 表示视图通常需要一些验证逻辑或 表示逻辑，例如显示名称与原始名称不同 对象名称。在这些情况下，最好保持表示逻辑 与业务逻辑分离，便于更改表示形式 逻辑或业务逻辑独立，甚至易于切换 用于不同UI设计或c语言的表示层