实体框架和 3 层架构答案

【问题标题】：Entity Framework and 3 layer architecture实体框架和 3 层架构
【发布时间】：2011-07-06 18:08:10
【问题描述】：

我有一个三层架构程序。问题是：
1.数据访问是EF的层吗？
2.如果我想使用EF从表示层生成的实体，那么我引用了数据访问，但这违反了3层架构的原则。

【问题讨论】：

croisharp 当您从表示层或在您的处理程序项目（逻辑）中引用您的 EF 模型时，您只是要求模型定义（类），您的数据库访问仍然保留在您的数据层中，所以别担心！

标签： c# .net entity-framework architecture

【解决方案1】：

Microsoft Spain 在 codeplex 上发布了一个非常好的文档、指南和示例应用程序，用于 N 层应用程序，您可以在此处查找：

http://microsoftnlayerapp.codeplex.com/

您会在那里找到许多方向和有用的实现模式。

第一次。

【讨论】：

【解决方案2】：

是的，EF 将是您的数据访问层。使用 EF，您可以使用支持 POCO 的 T4 模板，然后您可以将这些 POCO 提取到单独的 dll 中，这将被您的所有层引用。

【讨论】：

+1 使用 POCO 提供了所需的抽象级别，以确保维护架构的完整性。证据？您可以替换数据访问实现，但保留 POCO 作为数据合同。

【解决方案3】：

您正在构建什么类型的应用程序？如果你正在构建一个 ASP.NET MVC 3 应用程序，你可以让你的视图作为表示层，你的模型是你的数据访问（可以使用 EF），控制器和/或动作过滤器可以包含你的业务逻辑，并且在这个您将在表示层中使用 EF 模型但仍满足关注点分离原则的场景。

【讨论】：

我使用 netTcpBinding 构建 wcf 服务，但其架构提供 Web 服务软件工厂。如果我从我的服务实现引用数据访问，或者在表示层的任何其他应用程序中引用数据访问，这不会是架构错误？
我认为任何抽象模型的关键目标是限制依赖关系，因此如果您的 ServiceContract 中有一条 SQL 语句，那么我会说您的服务实现“过于依赖”您的数据访问。但是 EF 本身就提供了抽象。我建议您创建一个存储库类，从您的 EF 上下文中抽象您的服务。我在回答你的问题吗？
当然，我使用 Manager 进行了抽象，它执行 Delete、Edit、GetById、GetAll、Add 方法，但那是业务逻辑，我的意思是生成的实体，如 Customer、Producer.. .

【解决方案4】：

EF 做了两件事：-

1) 为您生成域模型（可选，但常用） 2) 使您能够通过该域模型查询/修改您的数据库。

这可能会使域模型和数据访问之间的界限变得模糊，但两者确实是分开的。

只要您不直接在表示层中创建对象上下文和编写查询之类的事情，恕我直言，您并没有破坏抽象——您“破坏”的唯一一件事是您需要引用 System .Data.Objects（或任何 EF dll）在您的演示项目（这只是一个物理工件）中，除非您按照 Jethro 建议的路线将您的域模型生成到一个单独的项目中。

【讨论】：

【解决方案5】：

对于三层架构。我会考虑使用域模型和数据模型模式进行抽象，而不是直接从表示层进行 EF。

所以想法是你的数据模型有 EF POCO 类和存储库，它知道如何为各种 CRUD 访问这些类。

您的域模型将具有与您的客户端相关的模型（因此您可以放置各种 ViewModel 或验证相关代码），它可以是 WPF 或 MVC Web 应用程序。现在在这两者之间有一个业务可以同时与域和数据模型进行对话。

您的表示层对 EF/数据层/存储库一无所知。当您想引入新的数据框架或数据库时，您只需要编写新的存储库类和数据模型类（可能会使用某种代码生成）。

这也使您的代码也可以进行单元测试。

【讨论】：