Entity Framework和3层架构

Question

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

- croisharp

---

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

Answer 1

微软西班牙在codeplex上发布了关于N层应用程序的很好的文档、指南和示例应用程序，您可以在这里查看：

http://microsoftnlayerapp.codeplex.com/

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

希望对您有所帮助。

- user604613

Answer 2

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

- Jethro

---

使用 POCO 提供所需的抽象级别，以确保架构的完整性得以维护。证明是什么？您可以替换数据访问实现，但保留 POCO 作为数据合同。 - Steve Morgan

Answer 3

你正在构建什么类型的应用程序？如果你正在构建一个ASP.NET MVC 3应用程序，你可以将你的View作为表示层，Model作为数据访问（可以使用EF），控制器和/或Action Filters可以包含你的业务逻辑，在这种情况下，你将在表示层中使用你的EF Model，但仍然满足关注点分离原则。

- Glenn Ferrie

---

我使用 netTcpBinding 构建 WCF 服务，但采用提供 Web 服务软件工厂的架构。如果我在服务实现中引用数据访问或在演示层中的任何其他应用程序中引用，那么这种架构不会出错吗？ - croisharp

我认为在任何抽象模型中的关键目标是限制依赖性，因此如果您在ServiceContract中有一个SQL语句，那么我会说您的Service实现对Data Access的依赖性“过高”。但是EF本身提供了抽象。我建议您创建一个仓储库类，将您的服务与EF上下文分离。我回答了您的问题吗？ - Glenn Ferrie

当然，我使用Manager进行了抽象化处理，它执行Delete、Edit、GetById、GetAll、Add等方法，但这是业务逻辑，我指的是像Customer、Producer之类生成的实体。 - croisharp

Answer 4

EF有两个作用：

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

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

只要您不在表示层中创建对象上下文并直接编写查询，那么在我看来，您就没有打破抽象化——您唯一“打破”的是您需要在表示项目中引用System.Data.Objects（或EF dll），除非您按照Jethro建议的方法将您的领域模型生成到单独的项目中。

- Isaac Abraham

Answer 5

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

因此，您的数据模型将具有带有知道如何访问这些类以进行各种 CRUD 操作的存储库的 EF POCO 类。

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

您的表示层不知道 EF/数据层/存储库的任何内容。当您想要引入新的数据框架或数据库时，您只需要编写新的存储库类和数据模型类（可能带有某种代码生成）。

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

- daehaai