1

データ アクセス層の作成には Entity Framework 4.0 を使用しました。次に、私のビジネス ロジック層には DAL と同じオブジェクトがありますが、いくつかの拡張機能 (つまり、より多くのプロパティ、いくつかの関数、セッターでのデータ検証など) があることがわかりました。

DAL と BLL を別々のプロジェクトに含めることを計画し、BLL でエンティティ クラスを使用してコードの冗長性を防ぐためのベスト プラクティスを探していました。

私が検索したところ、2つの主要なアイデアがあります。

  1. 部分クラスによる同じプロジェクト内のエンティティ クラスの拡張
  2. インターフェイスの使用 (エンティティ クラスおよび関連する BLL クラスによって実装されます)。前者はプログラマーの間でより人気があります。

上記のソリューションの欠点:

  1. 部分クラスの一部として同じプロジェクトにコードを追加する必要があります。これは、プロパティとメソッドを追加するのには適していますが、何かをオーバーライドするのには適していません (つまり、ビジネス ロジック レイヤーでプロパティを設定する前に検証を追加するなど)。
  2. エンティティ モデルが変更された場合は、エンティティ クラスからインターフェイスを手動で再度抽出する必要があり、BLL 関連のクラスにも別の変更が必要です (2 つの手動の回避策)。

私の質問は、関連するエンティティ クラスから BLL クラスを継承せず、メソッドとプロパティを拡張/オーバーライドしないのはなぜですか?

4

1 に答える 1

4

覚えておく必要があることの 1 つは、エンティティ フレームワークのような ORM は、実際には単純なデータ アクセス層を作成しないということです (一般的な 3 層アーキテクチャから見た場合)。それらが提供するのは、データアクセスのやり取りをわずかに細かく制御できる、より多くのビジネス層です。EF は本質的に DAL になり、コンテキストとエンティティの種類は BLL になる可能性があると主張できると思います。

モデル (EF レイヤー)、コントローラーまたはビューモデル (ビジネス ロジックが配置され、モデルをカプセル化する場所)、およびビューがある MVC または MVVM アーキテクチャの詳細を通して見ると、線がはるかに見やすくなります。

とにかく、EF は実際にはエンティティ型を直接インスタンス化する必要があるため、EF はサブタイプを返されるエンティティとして使用しないため、継承してもあまり効果がありません。EF での検証および同様のタスクの解決策は、部分クラス(ご存知のとおり) と部分メソッドの両方を利用することです。EF の既定のコード生成テンプレートは、 および のすべてのスカラー プロパティの部分メソッドを生成しOnPROPERTYNAMEChangingますOnPROPERTYNAMEChanged。

たとえばint UserId、エンティティ タイプにプロパティがある場合User、次のような部分クラスを作成できます。

public partial class User
{
    partial void OnUserIdChanging(int newUserId)
    {
        // do something
    }

    partial void OnUserIdChanged()
    {
        // do something
    }
}

もちろん、必要に応じてどちらか一方のみを使用することもできます。継承された呼び出しよりも部分メソッドが持つ利点 (それが可能であると仮定した場合) は、部分メソッドが非仮想であり (したがって、正しいメンバーを呼び出すための仮想テーブル ルックアップがない) 、クラスの一部としてのみコンパイルされることです。実際の実装。

つまり、デザイナー コードに移動して、

partial void OnUserIdChanging(int value);
partial void OnUserIdChanged();

関数にメソッド本体を実際に追加しない場合、C# コンパイラは関数とそのすべての呼び出しをコードから完全に削除します。これにより、型が小さくなり、他のプロパティへの呼び出しが高速になります。これは、空の関数を呼び出す必要がないためです。

于 2011-02-10T21:55:29.577 に答える