在 POCO 对象中存储 DbContext 引用会出现什么问题？答案

【问题标题】：What problems can arise from storing a DbContext reference in a POCO object?在 POCO 对象中存储 DbContext 引用会出现什么问题？
【发布时间】：2013-04-04 23:52:50
【问题描述】：

我是一个 15 岁的应用程序的新手。团队负责人已开始使用 Entity Framework + 以及现有的 WebForms + Sprocs。

EF 中的一些 POCO（域实体）具有包含对 DbContext 的引用的属性，通常是对象图顶部的父对象。当我尝试编写测试时，我不断收到 Context Disposed 异常。

    public EmployerService(int UserID, Entities entities) // business layer
    {
        this.UserID = UserID;
        _entities = entities;
    }        


    internal Employer CreateEmployer()
    {
        Employer  employer = _entities.Employers.Create();
        employer.MasterItem = _entities.MasterItems.Create();
        employer.MasterItem.LastModified = _entities.ItemLastModifieds.Create();
        employer.DBContext = _entities;
        ...
        return employer;
    }

更重要的是，项目引用不干净。 POCO 引用数据和业务逻辑层。我正在构建一个案例以从 POCO 对象中获取 DbContext 引用，但我的搜索才刚刚开始。

所以我的问题是，哪些设计原则支持或拒绝从 POCO 引用 DAL 层？

【问题讨论】：

这看起来还没有真的不好。看起来它更像是一个上下文生命周期问题（上下文存在时间太长）。域实体中是否也有对上下文的引用？（就像Employer 本身一样）。那会很糟糕。

标签： entity-framework unit-testing c#-4.0 design-patterns

【解决方案1】：

您的 DAL 层潜入业务逻辑层。服务现在与实体框架紧密耦合（顺便说一句，我认为将 EntityFramework.dll 的引用添加到您的域项目中不是一个好主意）。考虑我们正在迁移到 NHibernate。你应该改变什么？每个人都会认为这是 DAL 任务。但是等等，我的域中有一些 DAL！我们应该改变 EmployerService 类。

因此，请保持您的域实体始终处于无知状态。尤其是让他们对您正在使用的具体持久性技术一无所知。我认为创建雇主的更好地方是工厂。另外我不明白你为什么不在这里使用简单的构造函数？看起来您可以在创建雇主期间避免使用实体框架。

【讨论】：

这是现有代码。我是团队的新手，正在努力说服他们做出改变，但团队领导时间的限制让他不想冒险。
@JCii 看起来您的团队不使用单元测试，现在一切正常。您从他们的目的中要求的是简单的重构，这不会带来一些有价值的（当前）好处，但需要对整个应用程序进行回归测试。在遗留项目上总是很难要求重构

【解决方案2】：

vocaldesign principle 最多的是您在当前设计中遇到问题。

DbContext 应该用作short-living - 并且不打算存储for later。您所持有的参考资料没有多大意义，因为它得到了Disposed。

至少你应该检查它是否是Disposed（我猜你可以通过覆盖Dispose，设置一个标志或其他东西来做到这一点）。 但如果是的话怎么办？

基本上，如果你仍然那样使用它——确保你的 POCO 对象也是“短命的”——但我敢肯定那会很痛苦。

【讨论】：