0

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

4

2 回答 2

1

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

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

于 2013-04-04T06:33:09.923 回答
0

最重要vocal design principle的是您在当前设计中遇到问题。

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

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

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

于 2013-04-04T15:52:50.067 回答