实体框架参考，多层应用答案

【问题标题】：Entity Framework References, Multi Layer App实体框架参考，多层应用
【发布时间】：2011-11-30 11:42:42
【问题描述】：

我已经为我的域 (POCO) 和存储库设置了具有单独类库的 MVC 应用程序。现在我的 DbConxet 目前在域层中，我想添加以下内容：

protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
    }

但它找不到 DbModelBuilder。现在我检查了我的引用并注意到它引用了 EFCodeFirst0.8/lib/EntityFramework.dll 当我将其更改为 EntityFramework4.2.0.0/lib/EntityFramework.dll DbModelBuilder 可用但我收到错误，因为我的解决方案中的其他项目（ MVC 和 Repo）正在引用原始 dll。所以我更新了它们，但是 MVC 层在 App_Start/SQLCEEntityFramework.cs 中有问题

我做错了什么？！我是否应该在我的应用程序的另一部分中使用 OnModelCreating 并将所有对原始 EFCodeFirst0.8/lib/EntityFramework.dll 的引用重置？或者修复 App_Start/SQLCEEntityFramework.cs 中的错误？

谢谢大家，

詹姆斯

【问题讨论】：

标签： asp.net-mvc asp.net-mvc-3 entity-framework entity-framework-4

【解决方案1】：

你做错了:)

当您在任何地方都引用了实体框架并且您的域与之绑定时，POCO、存储库模式以及所有用于持久性无知的东西真的没有意义。

您的域应该是纯类库（当然包含组件模型、数据注释之类的东西）而不引用 EF。

那么您应该在您的 MVC 应用程序和“所有可能的存储库”之间有“合同”（即接口，在另一个类库中） - 也与 EF 无关。

最后，您拥有该合同的“一个特定实现” - 您的 EF 存储库。那应该是唯一引用 EF 库的项目。

关键是，如果明天你的老板来说“好的，我们切换到 nhibernate”，你应该重播“没问题，我只是编写另一个实现这个接口的存储库，并在 IoC 容器配置中更改 1 行” .作为奖励，您只能在一处更新您的 EF 参考 :)

【讨论】：

好的，如果我有一个 Project.IRepository 类库，Service 层与之交谈/知道，然后是一个 Project.EFRepository 和 Project.IRepository 类的实现，其中包含对 EF 的引用，那会更好并有dbContext？我可以在我的 MVC 层中删除对 EF 的引用吗？
感谢 rouen，现在觉得它开始变得很有意义了！
你应该判断编码到持久无知所需的劳动量与你必须改变的几率（加上改变从来没有你想象的那么简单）。如果您的 Web 层对底层数据库一无所知，那么您最终可能会遇到许多令人痛苦的性能问题。此外，通过许多依赖项进行调试并不好玩。以我的经验，拥有存储库抽象永远不会得到回报。只需将 EF 上下文视为您的存储库，并根据需要在您的服务/控制器中使用它。
当然这取决于项目的大小。在小项目中，我同意你的方法，但我的回答是基于提供的事实 - 已经使用存储库模式、持久性无知域对象等，所以我想他有理由使用它们，我只是纠正了他在使用它们时的错误。