ビジネスオブジェクト

Question

に私を保存私は、一般的に、ビジネス・オブジェクト上でこのような例を見てきましたか？これは、ビジネスロジックよりもコンテキストやデータに関連しているようです。

例えば、このような何かを経るかもしれません。このオブジェクトの消費者...

...Get form values from a web app... 

Thingy thingy = Thingy.CreateNew(Form["name"].Value, Form["gadget"].Value, Form["process"].Value); 
thingy.Save(); 

あるいは、更新のためにこのような何か...

... Get form values from a web app... 

Thingy thingy = Thingy.GetThingyByID(Int32.Parse(Form["id"].Value)); 
Thingy.Name = Form["name"].Value; 
Thingy.Save(); 

は、なぜこれがあります？計算やビジネス固有のルールなどの実際のビジネスロジックを含んでおらず、検索/永続性を避けるのはなぜですか？このアプローチを使用

、コードは次のようになります。これらの例の両方で

... Get form values from a web app... 

Thingy thingy = Thingy.CreateNew(Form["name"].Value, Form["gadget"].Value, Form["process"].Value); 
ThingyRepository.AddThingy(ref thingy, out id); 

あるいは、更新のためにこのような何か...

... get form values from a web app ... 

Thingy thingy = ThingyRepository.GetThingyByID(Int32.Parse(Form["id"].Value)); 
thingy.Name = Form["Name"].Value; 
ThingyRepository.UpdateThingy(ref thingy); 

、消費者、人オブジェクトに対して何が行われているかを最もよく知っており、リポジトリを呼び出し、ADDまたはUPDATEを要求します。オブジェクトはそのコンテキストではDUMBのままですが、引き続き検索または永続化されるのではなく、それ自体に関連するコアビジネスロジックを提供します。

要するに、ビジネスオブジェクト自体の中でGETメソッドとSAVEメソッドを統合することのメリットはありません。

私は不平を言い合い、順応しなければならないのですか、何か不足していますか？

Answer 1

私はDDDを理解していませんが、1つの方法（これはUPSERTを行います。レコードが存在しない場合は挿入し、それ以外の場合は更新）を持つことは理にかなっています。

クラスのユーザーは、ダムを実行して既存のレコードに保存し、新しいレコードで更新することができます。 1つのアクションポイントを持つことがはるかに明確です。

編集：INSERTまたはUPDATEを行うかどうかの判断は、リポジトリに任せておく方が良いです。ユーザーはRepository.Save（....）を呼び出すことができます。これにより、新しいレコード（レコードがまだDBにない場合）または更新が行われる可能性があります。

Answer 2

自分のアプローチが好きでない場合は、自分で作成してください。個人的にビジネスオブジェクトのSave（）インスタンスメソッドは、本当に良いにおいをします。私が覚えておく必要があるクラス名が1つ少ないしかし、私は工場での保存に問題はありませんが、なぜそれが両方を持つのが難しいのか分かりません。 IE

class myObject 
{ 
    public Save() 
    { 
     myObjFactory.Save(this); 
    } 
} 
... 

class myObjectFactory 
{ 
    public void Save(myObject obj) 
    { 
     // Upsert myObject 
    } 
} 

Answer 3

あなたのドメインオブジェクトには、持続性の懸念事項はありません。

永続性サービスを表すリポジトリインターフェイスをドメイン内に作成し、それをドメイン外に実装します（別のアセンブリで実装できます）。

このようにして、集約ルートはリポジトリを参照する必要はありません（集約ルートであるため、必要なものはすべて既に存在するはずです）。依存関係や永続性の懸念がなくなります。したがって、テストしやすく、ドメインに集中します。

Answer 4

これは、Active Record pattern（P of EAA p. 160参照）につながります。

私は個人的に私はファンではありません。永続化メカニズムを変更するためにビジネスオブジェクトの変更が必要となるように、ビジネスオブジェクトと永続化メカニズムを緊密に結合しますか？データレイヤーとドメインレイヤーを混在させる？ single responsibility principleに違反していますか？私のビジネスオブジェクトがAccountの場合、私はインスタンスメソッドAccount.Saveを持っていますが、私は静的メソッドAccount.Findを持っているアカウントを見つけるには？ヤッキー。

つまり、その用途があります。データベーススキーマに直接準拠し、単純なドメインロジックを持ち、テスト、リファクタリング、依存性注入、オープン/クローズ、懸念の分離などの問題に関係しないオブジェクトを持つ小規模なプロジェクトの場合、それは良い選択です。