クラスデータの責任

Question

「発注書」クラスがあります。単一の注文書に関する情報が含まれます。データベースメソッド用のDAOクラスがあります。

注文書をロードして更新するメソッドの責任はどこにあるのでしょうか?

PurchaseOrder クラスには DAO クラスを直接使用する '.update'、'insert'、'delete'、および '.load' メソッドが必要か、それとも PurchaseOrder クラスは DAO メソッドを認識せず、これらを管理する POController クラスが必要か相互作用？

ユーザーは一度に 1 つの PurchaseOrder のみを処理します。

ありがとう！

Answer 1

発注書は、その永続性の詳細について無知でなければなりません。これはある種のデータアクセスレイヤーを持つポイントであり、オブジェクトの管理を処理し、オブジェクト自体は購入注文であることに集中できます。

これにより、模擬発注書を作成し、永続性の問題に巻き込まれないようにシステムがそれらを処理するロジックをテストできるため、システムのテストが容易になります。

Answer 2

PurchaseOrderをインターフェイスにし、すべてのDAOコードを実装に入れて、ファクトリーを使用することで、シンプルにします。

Answer 3

アプリケーションの存続期間に依存します。私の会社の金属切削アプリケーションは1985年以来継続的に開発されており、コンピューターアーキテクチャの複数の変更を通じて移植されてきました。私たちの場合、5、10、15年後の状態になるとは限らないので、ほぼ常にインターフェイス（または用語を使用したコントローラークラス）の背後にあるものを押し出します。

コントローラークラスを使用することで、上記のビジネスロジックとUIの調整レベルを変更することなく、基になるAPIを変更できます。これらのレベルは長年の作業を表しているため、その動作を維持することが重要です。

プロジェクトのライフタイムの大部分はメンテナンス期間になります。後でデザインを簡単に変更できるようにするために今やっていることは、今後の時間を大幅に節約できます。

Answer 4

PurchaseOrderクラスは、DAOを無視する必要があります。 purchaseOrderクラスは、データ自体を表す必要があります。コントローラまたはサービスマネージャ、またはDAOを使用してPurchaseOrderレコードを永続化/ロードするために呼び出すものを使用します。これにより、設計の柔軟性が最も高まります。データモデル用に1か所、PurchaseOrdersの保存/取得方法に関するビジネスロジック（コントローラー）用に1か所、および実際に永続化される場所が1つあります。

Answer 5

私の推論について説明します：

クラスメソッド
基本原則：永続性はクラスの動作であり、クラスメソッドでなければなりません
懸念事項を分離する必要があるので、データベースをnitty-grittyにDAOクラスに入れ、それをクラスから使用してメソッドを実装します。
最初の問題：異なるDAOのセットをサポートする必要がある場合は、ファクトリを介して作成する必要があります。 2番目の問題：すべての永続性の動作がクラスのインスタンスに特に関連しているわけではありません。たとえば、ListメソッドとSearchメソッド：クラスではなくクラスリストを返し、インスタンスに依存しません。したがって、これらは基本的に static メソッドです。
3番目の問題：このクラスの継承をサポートする必要があります。そのため、永続性の詳細は親ごとに異なります。静的メソッドがある場合、それは問題になります。

では、次へ進みます

コントローラー
基本原則：永続化メソッドは単一のクラスに属していません。より大きく、したがって分離する必要があります
懸念の分離が再び必要であるため、DAOが必要です。これはUtilityクラスなので、メソッドはすべて基本的に static です。
最初の問題：複数の永続化メソッドをサポートする場合は、DAOを作成するファクトリが必要です。
2番目の問題：静的クラスを使用できないように、クラスの階層をサポートしたい。ファクトリーを介してコントローラーを生成する必要があります。
3番目の問題：開発者に複雑すぎるAPIを提供している。
クライアントコードの例：

PurchaseOrder po;
PurchaseOrderController poc;
poc = PurchaseOrderControllerFactory.Instance.Create();
po = poc.GetPurchaseOrder(42);
// do stuff
poc.SavePurchaseOrder(po);

その後、ゼロから始めます。

行動から始める
基本原則：永続性は動作ではありません。行動は永続性よりも大きい。
システムには、発注書サブシステムがあります。ユーザーは、高レベル（ユースケースレベル）でのみ操作できます。そのため、メソッドは発注書のユースケースを実装します。これらのメソッドは、必要に応じてファクトリを介してDAOを使用して、データベースにアクセスし、必要なことを実行します。
つまり、PurchaseOrderは基本的にDTOであり、データをすばやく渡す方法です。振る舞いがあってはなりません。
クライアントコードの例：

// It could be a factory if needed.
PurchaseOrderSystem pos = new PurchaseOrderSystem(); 

List<PurchaseOrder> transacted;
transacted = pos.TransactPurchaseOrders(john, 23);

// Show transacted purchase orders or whatever...

Answer 6

「ビジネスロジック」を明確に分離します。 （PurchaseOrder）データベース相互作用/アクセスから。別のベンダーなどに移動した場合、ビジネスの実装を妨げる可能性がなく、アクセスを簡単に変更できます。また、データベースアクセスレイヤーへの動作の追加を回避することも簡単になります。

Answer 7

個人的には、相互作用を管理するオブジェクトを作成します。このロジックをPurchaseOrderクラス自体に入れないことを強く主張することはできませんが、このコントローラーオブジェクトを作成すると、より疎結合のオブジェクトになります。

Answer 8

ここで考えるべき重要なことは、将来何をしたいかということです。データベースを別のデータベースに置き換えたいと考えていますか?そのため、データベースと対話するコードを、PO​​ を表すクラスから確実に分離する必要があります。これは基本的な責任の分離であり、すでにそれを実行していることを願っています。

さて、質問は次のとおりです。PO クラスと DAO クラス間の対話を管理する 3 番目のクラス (コントローラー) が必要ですか?それは、DAO クラスへのインターフェイスをどれだけ一般的にできるかによって決まると思います。DAO インターフェイスが十分に一般的で、インターフェイスを変更せずに、別のストレージ メカニズムを使用してそれに代わるプラグインを作成できる場合は、PO クラスがそれと対話できるようにします。そうでない場合は、コントローラー クラスを作成します。

もう一つ考慮すべきことは、構造の残りの部分です。セーブ/ロードはどこから開始されますか?PO の多くの操作 (保存、ロード、印刷、顧客への送信) を行う場合は、機能を PO クラスに統合するのではなく、それらすべてを実行するコントローラーを用意する方がおそらく合理的です。 。これには、PO クラスを変更せずに PO 操作を追加できるという利点があります。