实体框架和3层架构

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

2011-07-05 croisharp

croisharp当你从表现层或在您的处理程序项目（逻辑），你只是在寻求模型定义（类），你的数据库存取仍停留在你的数据层参考你的EF模型，所以不用担心！ – euther

是EF将是您的数据访问层。借助EF，您可以使用带有POCO支持的T4模板，然后您可以将这些POCO提取到单独的dll中，这将成为您所有图层的参考。

2011-07-05 19:08:05 Jethro

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

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

2011-07-05 19:21:07

我使用netTcpBinding构建wcf服务，但是使用提供web服务软件工厂的体系结构。这不会是在架构一个错误，如果我从服务实现中引用的数据访问，或者在表示层任何其他应用程序？ – croisharp

我觉得在任何抽象模型的关键目标是限制依赖关系，因此，如果你在你的ServiceContract有一个SQL语句，然后我会说，你的服务实现对数据访问“过于依赖”。但EF本身就提供了抽象。我想为你建议的是创建一个存储库类，从你的EF上下文中抽象出你的服务。我是否回答你的问题？ –

当然，我与经理的抽象，它执行删除，编辑，GetById，GETALL，添加方法，但这是业务逻辑，我的意思是这是像客户，制片人产生的实体... – croisharp

EF做了两两件事： -

1）生成您的域模型（可选的，但通常使用的） 2）为您提供查询/经由域模型修改数据库的能力。

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

只要你没有在创建对象上下文和直接在你的演示文稿中编写查询这样的东西，你就不会破坏抽象 - 你唯一需要“分手”的事实就是你需要引用除非您按照Jethro建议的路线将您的域模型生成到单独的项目中，否则您的演示项目中的System.Data.Objects（或任何EF dll）（这只是一个物理工件）。

2011-07-06 08:16:08

微软西班牙发布在CodePlex上n层应用的一个很好的文件，指导和示例应用程序，你可以看看它在这里：

您将多个方向和乐于助人的实现模式有找。

hth。

2011-07-06 08:18:35 UrbanEsc

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

所以这个想法是，你有你的数据模型有EF POCO类与知识库知道如何访问这些类的各种CRUDs。

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

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

这也允许你的代码也是单元可测试的。

2011-07-06 10:08:10 daehaai

回答