实体框架 n 层解决方案答案

【问题标题】：Entity Framework n-tier solution实体框架 n 层解决方案
【发布时间】：2011-10-23 11:11:39
【问题描述】：

我正在创建一个与本示例所使用的设计密切相关的新项目。

http://www.toplinestrategies.com/dotneters/net/wcf-entity-framework-and-n-tier-solutions-part-2/?lang=en

我有一个 WPF 或 ASP.NET 应用程序，它与 WCF 服务通信，然后将其发送到业务层以完成大部分工作。

生成 POCO 对象，然后将该模板移至模型项目，这将允许我访问业务和数据层中的这些对象。我的问题是数据访问层在这种情况下提供什么目的？它似乎只保存 .edmx 文件。

这是标准做法，还是我只需将 .edmx 文件放入业务层就能提高效率？

【问题讨论】：

标签： entity-framework poco n-tier-architecture

【解决方案1】：

DAL 通常提供模型和数据库表之间的映射。根据您的描述，您将映射部分移动到模型中。不过，我不确定这是一个好习惯。例如，作为数据库表，您也需要更改/构建模型项目。如果您稍后决定使用 NHibernate 而不是 EF 怎么办？由于这些原因，我认为映射应该在 DAL 中，而 DAL 可以是一个单独的项目。

【讨论】：

那么您的建议是我忽略模型层，只从业务逻辑层引用数据层以传递 POCO 对象？还是我的数据层应该包含业务逻辑？
出于类似的原因，我会将 BLL 和 DAL 分开。在 BLL 中，我将使用通用存储库类从 DAL 获取数据。
原谅我不理解。但是使用存储库类比使用生成的 POCO 有什么好处呢？
我认为最大的好处是独立于任何特定的数据访问方法。如果您直接使用 POCO 上下文，那么您的整个 BLL 都依赖于 EF 上下文。但是当你在 BLL 中使用存储库接口时，它就没有了。以后，如果你想使用，SQL CE，你可以只实现那个接口。 BLL 不依赖于任何数据访问方法。
您是否有任何指向您所讨论内容的示例的链接。我已经看到了很多关于使用存储库接口的信息，但是它们似乎都使用了 POCO 对象——否则你怎么知道你返回的是什么对象？