0

私は 15 年前のアプリケーションを初めて使用します。チーム リーダーは、既存の WebForms + Sprocs と共に Entity Framework + の使用を開始しました。

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

Your DAL layer sneaks into Business Logic layer. Service now tightly coupled to Entity Framework (BTW I don't think it's good idea to add reference to EntityFramework.dll into your domain project). Consider we are moving to NHibernate. What you should change? Everybody would think it's a DAL task. But wait guys, I have some DAL in my domain! We should change EmployerService class.

So, keep your domain entities persistent ignorant. Especially keep them ignorant of concrete persistence technology you are using. And I think better place for Employer creation is a factory. Also I don't understand why you are not using simple constructors here? Looks like you can avoid Entity Framework usage during Employer creation.

于 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 に答える