Question

我是一个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层？

Answer 1

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

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

Answer 2

vocal design principle这里的<{>} ，你有问题与当前的设计。

DbContext应该用作short-living - 它并不意味着存储for later。你持有的引用并不重要，因为它得到Disposed。

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

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

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

2 个答案: