1

すべてのプロジェクトでの私の基本的なソリューション構造は次のとおりです。

  • Dal - データ アクセス層
  • 2 つのセクションに分割されたビジネス ロジック 1 つはビジネス エンティティ、2 番目はビジネス ロジック

したがって、私の現在のプラクティスでは、エンティティにはデータ メンバーとプロパティのみが含まれ、CRUD 操作は含まれません。エンティティ内に CRUD 操作を配置するのは常に間違っていると感じています。私の考えは..

  • どのエンティティが自分自身を削除しても問題ありませんか?
  • どのエンティティが自分自身を DB に追加しても問題ありませんか?

そこで、CRUD 操作を、ビジネス ロジックを表す別のライブラリ (クラス) に移動しました。

たとえば、 foo エンティティがあるとしましょう

public class Foo
{
    //Data Members
    private int _id;
    private string _Name;

    //Properties
    public int ID { get; set; }
    public string Name { get; set; }
}

したがって、このエンティティに対して、すべての CRUD 操作を保持する FooLogic ライブラリ (クラス) を作成します。

  • 新しいエンティティを追加
  • エンティティを削除する
  • エンティティのリストを取得する
  • エンティティを更新するなど..

だから私が求めているのは：

  1. エンティティ オブジェクト内に CRUD 操作を配置しないのは正しい方法ですか?
  2. もしそうなら、「印刷の詳細」の横にあるエンティティ自体にどのようなメソッドを配置する必要がありますか
  3. 重要なエンティティごとにビジネス ロジック ライブラリ (クラス) を用意してもよいですか?
4

2 に答える 2

3

すべての状況で何が絶対に正しいかについて話すことはできません (何もそうではないだけでなく、私が真の「エンタープライズ」開発者ではないため)、しかし...

  1. 挿入や更新などのデータベース/エンティティ操作は、通常、すべてのデータベース操作をカプセル化する Repository クラスによって処理されます。リポジトリ メソッドは、データベース レコード (適切な ORM がある場合はレコード) を表すエンティティ クラス オブジェクトを受け入れるか、または返します。エンティティ オブジェクトは POCO である必要があり、それ自体をデータベースに直接結び付けるロジックを含めないでください。これにより、デフォルトのリポジトリ実装をモックに交換できるため、テストが非常に簡単になります。
    • .NET の世界では、EFDbContextは既にリポジトリであることに注意してください。自分でリポジトリ パターンを再実装する必要はありません。
  2. エンティティ オブジェクトのメモリ内状態で動作するアクセサーとミューテーターのみ。これには単純なプロパティが含まれますが、たとえばフィールド とフィールドPerson.GetFullName()を連結するものなども含まれます。Person.FirstNamePerson.LastName
    • そのため、実際には Person に対する操作ではなく、電子メール システムに対する操作であるため、Personクラスのメソッドを呼び出す必要はありません。SendEmailTo()
  3. 一般的に言えば、いいえ。ビジネス ロジックは、着信メッセージ (クライアント イベントやポーリング タイマーなど) に応答して発生する必要があり、単なるリポジトリ タスクとは別の問題です。

単純な CRM を実装する方法は次のCustomerとおりです (単一のエンティティである )。

エンティティ クラスDBCustomer:

(おそらく Entity Framework によって生成されます) は、データベースに格納されている顧客を表します。

class DBCustomer {
    public String FirstName { get; set; }
    public String LastName  { get; set; }
    public String FullName  { get { return this.FirstName + " " + this.LastName; } }
}

リポジトリ

Entity FrameworkDbContextはリポジトリ オブジェクトであるため、ここで作業を行う必要はありません。

ビジネスの論理

...WCF メッセージ ハンドラーなど - ただし、特にビジネス アクションがデータベース アクションに直接対応する場合など、ロジックが非常に単純な場合があります。

StatusCode Customer_Add(CustomerXml newCustomerXml) {
    DBCustomer newCustomer = createNewCustomerFromXmlMessage( newCustomerXml );

    using( MyDbContext dbc = CreateDbContext() ) {
        dbc.Customers.Add( newCustomer );
        dbc.SaveChanges();
    }

    return StatusCode.Success;
}

ここで、役に立たないレイヤーがたくさんあることに気付くかもしれません。CustomerXml クラス (逆シリアル化された以前の XML 形式のメッセージを表す) を使用して、EF コンテキスト メソッドを WCF メッセージ イベント ハンドラーから直接呼び出すことができます。非常に些細なプロジェクトでは機能しますが、プロジェクトが大きくなるにつれて、すべてのステップでカスタム ロジックを追加する必要があることがわかり、突然物事がすぐに管理不能になります。

したがって、単純なデータ駆動型の Web サイトの場合、単純な「ame レイヤーですべてを行う」アプローチはうまく機能しますが、仕様に多くの細かな点がある「エンタープライズ」アプリケーションでは、これらの追加のレイヤーが必要になります。

于 2012-09-23T07:43:00.457 に答える
1

1,2 について - オブジェクト永続化ツールと ORM には、ActiveRecord パターンと Repository または DataAdapter パターンの 2 つの異なる一般的なアプローチがあります。ActiveRecord は CRUD やその他の操作をエンティティ オブジェクト内に配置するものであり、リポジトリ パターンはエンティティ (DTO) をそれらの操作から分離します。
Active Record パターンには独自の利点があります (簡単だと言われています) が、より柔軟でテストしやすいため、Repository を好みます。

3- 個々のエンティティごとにプロジェクトを作成するメリットは何ですか。それが良いアイデアであるかどうかはわかりません。

于 2012-09-23T08:21:49.703 に答える