MVC项目在企业级的设置。预期是什么？

Question

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

我正在寻求关于专业人士如何在企业层面上这样做的建议.

关于这一点，我看到了不同的流派，有些人是以真正的N层方式设计的，另一些人更喜欢先在MVC应用程序中直接使用EF代码，并且有FAT模型，有点像一个大型MVC应用程序，有逻辑上的关注点分离等等。

因此，对于一个中等规模的项目，这是我的设置，我想征求你的意见。

MVC应用程序

模型--在这里，我的模型有视图需要的东西、验证逻辑等等。这些模型的设计仅仅是为了在控制器和视图之间传递数据。

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

服务层

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

数据仓库层

数据层是围绕EF的薄包装器，并执行CRUD操作。通常，我将有一个代码优先的方法，其中实体模型是为我创建的EF。我首先将EF代码首先模型转换为域模型，然后将它们返回到服务层。数据层还期望来自服务层的域模型，然后我将其转换为EF代码优先模型，并持久化到DB。

域模型层

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

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

Answer 1

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

唯一真正需要记住的是，ASP.NET MVC非常松散地遵循MVC模式。不存在真正的MVC模型，试图将类似于实体类的东西强加到模型中是一个巨大的错误。您的模型是实体类、表示该类的视图模型和服务层中的查询逻辑的组合和交互。

Answer 2

我希望你建议在你的项目中有这些层次--

Entites层--它应该只包含模型folder.Nothing中的所有poco类。

数据层----它应该包含Db交互逻辑。另外，您的Dbcontext类应该驻留在这里。您可以使用存储库模式和工作单元模式来更好地分离concern.Use依赖项注入，以使用unit (还有许多其他容器也可用)解决依赖关系，.Please查看了这些设计模式，container.there是许多在网络上可供this.Simply使用的文章。

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

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

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