通过阅读此处发布的几篇文章，我得到了有关如何正确配置项目的错误信息。
我正在寻找有关专业人士如何在企业级别进行此操作的建议。
我看到不同的学校，有些人以真正的N-Tier方式设计，其他人更喜欢直接在MVC应用程序中使用EF Code First，并且有FAT模型和有一个大逻辑分离的MVC应用程序关注等等。
所以对于一个中型项目来说这是我的设置，我想问你对它的看法。
MVC应用
模型 - 这里我的模型具有视图需要的内容，验证逻辑等。这些模型旨在仅在控制器和视图之间传递数据。
控制器 - 调用业务逻辑所在的服务层，并在需要时获取域模型。将域模型转换为视图模型，反之亦然。
服务层
这是业务（域）逻辑的生命。 服务层还负责与数据层通信以执行CRUD操作。 服务层将域模型返回到MVC应用程序中的控制器，并且还在调用时期望域模型。
数据存储库图层
数据层是EF周围的薄包装器，可执行CRUD操作。 通常我会有一个Code First方法，EF为我创建实体模型。 我将EF代码的第一个模型转换为域模型，并将这些模型返回到服务层。 数据层还需要来自服务层的域模型，然后我将第一个模型转换为EF代码并持久保存到数据库。
域模型层
这些是通过应用程序层使用和共享的域模型。
什么是最好的设计？ 企业层面的预期是什么？
答案 0 :(得分：1)
你所采用的方法没有什么特别的错误。但是，我确实认为它过于复杂。特别是，您的存储库层是一个完全不必要的抽象级别。您只需将EF内容滚动到服务层并将其调用一天即可。必须将实体转换为域模型然后转换为视图模型，坦率地说，这是一种痛苦。只需将您的实体映射到您的视图模型并返回。
你唯一应该记住的是ASP.NET MVC 非常松散地遵循MVC模式。没有真正的MVC Model 这样的东西，并试图强迫像实体类这样的模具是一个巨大的错误。您的模型是您的实体类，代表该类的视图模型以及您在服务层中收集的查询逻辑的组合和交互。
答案 1 :(得分：0)
我希望您建议在项目中使用这些图层----
参与图层 它应该只包含模型文件夹中的所有poco类。没有其他
数据层---- 它应该包含Db交互逻辑。 您的Dbcontext类也应该驻留在此。 您可以使用Repository Pattern和工作单元模式来更好地分离关注点。使用依赖注入来解析使用Unity Container的依赖关系（还有许多其他容器也可用）。请看看这些设计模式和容器。有很多文章可以在网上找到。只需彻底了解它们。
服务层---- 它应该只包含调用控制器的服务方法，因为你的控制器不应该直接与数据层通信。它是一种更好的方法，可以防止你的业务逻辑暴露在外部攻击中。
MVC图层或UI图层--- 它应该只包含其工作是调用其中的服务和业务逻辑的控制器。 和查看文件夹，我们将所有视图显示给最终用户。
这是一个非常大的问题。我希望你能从中得到一些想法。