0

私はこれを一度読んだことがあります：

「正当な理由がない限り、エンティティをゲッターとセッターのバッグのままにして、それらのメソッドを別のレイヤーに配置しないでください」

私の顧客、注文、... オブジェクトは SqlDataReaders からデータを取得するだけです。ゲッターとセッターしかありません。

私の最初の質問は、誰かがエンティティにメソッドを実装し、これらのメソッドが何をしているのかということです。

4

2 に答える 2

4

この考え方は、ドメイン駆動設計コミュニティから来ています。

DDD では、ユーザーが要求する機能をキャプチャするドメイン モデルを作成します。エンティティは、機能と必要なデータを持つように設計します。それらを集約してグループ化し、構築（ファクトリ）とクエリ（リポジトリ）を担当する個別のクラスを用意します。

ゲッター/セッターしかない場合は、「Anemic Domain Model」があります。Martin Fowler がこの記事でそれについて書いています。

貧血ドメイン モデルの問題は、データベースをオブジェクトにマッピングするオーバーヘッドがありますが、そのメリットがないことです。エンティティを実際のドメイン モデルとして使用しない場合は、データに DataTable などを使用し、ビジネス ロジックを別の関数に保持してみませんか? Anemic Domain モデルは避けるべきアンチパターンです。

また、エンティティを自分でマッピングすることにも言及しています。このブログでは、オブジェクト リレーショナル マッピング ツールの使用が本当に役立つ理由について説明します。Code First アプローチで Entity Framework を使用すると、データと機能の両方を備えたクリーンなドメイン モデルを作成し、それをデータベースにマップすることができます。そうすれば、両方の長所を活かすことができます。

于 2012-07-27T17:14:38.833 に答える
1

モデルの一部としてメソッドがある場合は、モデル固有のタイプのロジックのみを含める必要があります。たとえば、銀行口座を考えてみます。

public class Account {
   public AccountId Id { get; set; }
   public Person Customer {get; set; }

   public void Credit(Money amount) { ... }
   public void Debit(Money amount) { ... } 

}

Credit と Debit はモデル固有のロジック (アプリケーションの他の場所にはありません) であり、Account クラスにカプセル化する必要があります。

また、モデル クラス内で SqlDataReader を使用してデータベースからデータを取得したことにも言及しました。これは大きなアンチパターンです。これで発生する問題は次のとおりです。

  1. 単一責任の原則に違反する - モデルは現在、データを表し、データベースからデータを取得する責任があります。
  2. モデル内の子にクエリを実行するのはどうですか? ぐちゃぐちゃになります。
  3. データアクセスを簡単に変更することはできません。

モデルをスリムに保ちます。データ アクセス ロジックをリポジトリ、つまり AccountRepository に配置します。

于 2012-07-27T17:08:55.790 に答える