使用 EF 构建 ASP.Net MVC 3答案

【问题标题】：Architecting ASP.Net MVC 3 with EF使用 EF 构建 ASP.Net MVC 3
【发布时间】：2011-12-21 08:56:18
【问题描述】：

我正在尝试构建我的 MVC Web 项目，但遇到了一些问题。

我正在使用 EF4.1。我用 EDMX 文件创建了一个 DataAccess 项目。然后我使用 dbContext 生成器来制作我的 POCO .tt 类。

就像现在一样，我的业务逻辑层可以正常访问 POCO 类，但表示层不能。

我认为我应该创建另一个抽象级别并将 dbContext .tt 文件放入他们自己的项目中，以便 BusinessLogic 层和表示层都可以访问 POCO 类，但只有 BusinessLogic 可以访问实体框架。表示层不需要了解任何有关 EF 的信息。

这样的……

POCO Classes - DataAccess
    |             |
    |---------Business Logic
    |             |
    |_________Presentation

我是否在正确的轨道上，如果是这样，我是否只需将 .tt 文件剪切/粘贴到新项目中，还是有办法强制 dbContext 插件在我的其他项目中创建这些文件？

【问题讨论】：

标签： asp.net-mvc-3 architecture entity-framework-4.1 poco

【解决方案1】：

您的表示层不必了解有关 EF 的任何信息。只需从表示层引用该项目即可访问模型。

但是 - 您的表示层不应该使用任何这些 POCO 模型。他们应该使用 ViewModel。我不一定相信这里的 DTO，因为 DTO 有特定的目的。您的存储库/数据访问可以返回模型，但通常这些模型会返回到服务层。然后，服务层会将您的 ViewModel 表示返回给您的控制器。

这也为依赖注入做好了准备，因为您只需将服务层注入到您的控制器中。您可以将所需的任何存储库注入到您的服务中，等等。

具有讽刺意味的是，我想我可能很快就会为这个确切的主题写一本书：)

【讨论】：

所以我一直在研究 ViewModels，我想我理解这个概念。我的下一个问题：创建 ViewModel 时是否在我的模型中引用 POCO 类？我见过的大多数示例似乎都访问了某种存储库，通常称为 _accountRepository。但我不确定这些存储库存储在结构中的什么位置。
我将保存在数据访问项目中的存储库。存储库将返回您的 EF poco 对象（或任何 poco 对象）。在一个单独的项目中，我将拥有我的逻辑，即服务。有些人选择在他们的模型类上使用扩展方法，这些方法将转换为视图模型。我在我的服务层执行此操作，例如 GetCustomerEditViewModel(int customerId) 获取我的实体，然后将其映射到 poco。请参阅此处的 Jimmy Bogards 文章：lostechies.com/jimmybogard/2009/06/30/how-we-do-mvc-view-models 我喜欢将自动映射属性实现转换为 VM .

【解决方案2】：

考虑在业务逻辑层和表示层之间发送Data Transfer Objects。这将允许您为您的视图塑造数据，并防止信息泄漏到表示层（例如，如果您的 POCO 中有业务逻辑需要但不需要在表示层中可用的字段)。

问题是，您将如何将数据移入和移出表示层？换句话说，表示层应该持有对域模型程序集的引用？（在实体框架中在场景中，域模型程序集只是创建出来的 DLL EDMX 文件。）

从纯粹的设计角度来看，DTO 是一种非常接近于完美。 DTO 有助于进一步将演示与服务层和领域模型。使用 DTO 时，表示层和服务层共享数据合同，而不是比类。

一层 DTO 将领域模型与表示隔离开来，导致松耦合和优化的数据传输。

如果您走这条路，还请查看 Automapper 以帮助将您的 DTO 映射到 POCO，反之亦然。

【讨论】：

我认为他的意思是他想将 POCO 用作 DTO。如果你不标记 poco 并使用流利的映射来满足需求，那是很有可能的。

【解决方案3】：

因此，有几种方法可以构建您的项目。您指的是一种方式，您可以在所有层之间共享 poco。

另一种方法是让您的 POCO 位于数据和业务层中，然后创建一个在 UI 和业务层之间共享的类似对象模型。最后，您还可以为 UI 创建第三个模型，仅称为 ViewModel。

这完全取决于您的需求。如果您的对象模型非常复杂，那么您可能需要使用 ViewModel 对其进行简化。

【讨论】：