企业级的 MVC 项目设置。有什么期望？

Question

通过阅读此处发布的几篇文章，我得到了关于如何正确配置项目的不匹配信息。

我正在寻求有关专业人士如何在企业层面做到这一点的建议。

我看到了不同的流派，有些人以真正的 N 层方式进行设计，其他人更喜欢直接在 MVC 应用程序中使用 EF Code First 并拥有 FAT 模型，并且有点拥有一个具有逻辑分离的大型 MVC 应用程序顾虑等。

所以对于一个中型项目，这是我的设置，我想征求您的意见。

MVC 应用程序

模型——这里我的模型正好有视图需要的东西、验证逻辑等。这些模型旨在仅在控制器和视图之间传递数据。

控制器——调用业务逻辑所在的服务层，并在需要时取回域模型。将领域模型转换为视图模型，反之亦然。

服务层

这就是业务（领域）逻辑的生命。 服务层还负责与数据层通信以执行 CRUD 操作。 服务层将域模型返回给 MVC 应用程序中的控制器，并且在调用时也需要域模型。

数据存储层

数据层是 EF 的薄包装器并执行 CRUD 操作。 通常我会采用 Code First 方法，EF 为我创建实体模型。 我将 EF 代码优先模型转换为域模型并将它们返回给服务层。 数据层还期望来自服务层的域模型，然后我将其转换为 EF 代码优先模型并保存到数据库中。

领域模型层

这些是通过应用程序层使用和共享的域模型。

什么是最好的设计？ 企业层面的预期是什么？

Answer 1

您提出的方法没有什么特别错误的。但是，我确实认为它过于复杂。特别是，您的存储库层是一个完全不必要的抽象级别。您可以简单地将 EF 的东西滚动到您的服务层中，然后就可以结束了。坦率地说，必须将实体转换为域模型，然后再转换为视图模型，这很痛苦。只需将您的实体映射到您的视图模型并返回。

您真正应该记住的唯一一件事是 ASP.NET MVC 非常 松散地遵循 MVC 模式。没有真正的 MVC Model 这样的东西，试图将实体类之类的东西强加到该模型中是一个巨大的错误。您的 Model 是实体类、表示该类的视图模型以及隐藏在服务层中的查询逻辑的组合和交互。

Answer 2

我希望您建议在您的项目中使用这些层----

实体层-- 它应该只包含模型文件夹中的所有 poco 类。没有别的

数据层---- 它应该包含 Db 交互逻辑。 您的 Dbcontext 类也应该驻留在此。 您可以使用存储库模式和工作单元模式来更好地分离关注点。使用依赖注入使用 Unity Container 解决依赖关系（还有许多其他容器可用）。请查看这些设计模式和容器。有很多文章可在网上找到。只需彻底浏览它们。

服务层---- 它应该只包含调用您的控制器的服务方法，因为您的控制器不应该直接与数据层对话。它是一种更好的方法，可以防止您的业务逻辑受到外部攻击。

MVC 层或 UI 层 --- 它应该只包含那些工作是在其中调用服务和业务逻辑的控制器。 和 View 文件夹，我们将所有视图显示给最终用户。

这是一个很大的问题。我希望你能从中得到一些想法。