在POCO对象中存储DbContext参考可能会产生哪些问题？

我是一个15岁的应用程序的新手。团队负责人已经开始使用Entity Framework +以及现有的WebForms + Sprocs。在POCO对象中存储DbContext参考可能会产生哪些问题？

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层？

来源

2013-04-04 JCii

这看起来还不错。它看起来更像是一个上下文生命周期问题（上下文存在时间过长）。在域实体中是否也有对上下文的引用？（就像'雇主'本身）。 _那会很糟糕。 – 2013-04-04 07:08:46

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

因此，让您的域名实体永远无知。特别是让他们不知道你正在使用的具体持久性技术。我认为雇主创造的更好的地方是工厂。另外我不明白你为什么不在这里使用简单的构造函数？看起来你可以在雇主创建期间避免Entity Framework的使用。

来源

2013-04-04 06:33:09

它是现有的代码。我对这个团队很陌生，并且努力说服他们改变，但是对团队领导时间的限制使他不想冒险。 – JCii 2013-04-04 06:39:35

@JCii看起来像你的团队不使用单元测试，现在所有人都在工作。你从他们的目的要求的是简单的重构，这不会给一些有价值的（当前）好处，但是需要对整个应用程序进行回归测试。重构总是很难要求遗留项目 – 2013-04-04 06:46:20

最vocaldesign principle这里是你有问题与目前的设计。

DbContext应该作为short-living使用 - 并不意味着存储for later。您持有的参考资料并不多，因为它取得Disposed。

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

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

来源

2013-04-04 15:52:50 NSGaga

在POCO对象中存储DbContext参考可能会产生哪些问题？

回答

相关问题