design-patterns - クラスデータの責任

Question

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

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

PurchaseOrder クラスに、DAO クラスを直接使用する '.update'、'insert'、'delete'、および '.load' メソッドがあるか、または PurchaseOrder クラスが DAO メソッドを認識せず、これらを管理する POController クラスを持っている必要があります。相互作用？

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

ありがとう！

score 4 · Accepted Answer

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

これにより、システムのテストも容易になります。仮の発注書を作成し、永続性の問題に巻き込まれることなく、システムがそれらを処理する方法のロジックをテストできるからです。

score 1 · Accepted Answer

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

score 0 · Accepted Answer

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

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

プロジェクトのライフタイムの大部分はメンテナンスにあることを覚えておいてください。後で設計を簡単に変更できるようにするために今行っていることは、将来的に大幅な時間の節約につながります。

score 0 · Accepted Answer

PurchaseOrder クラスは、DAO を認識しない必要があります。purchaseOrder クラスはデータ自体を表す必要があり、それ以上のものはありません。DAO を使用して PurchaseOrder レコードを永続化/ロードするには、コントローラーまたはサービスマネージャーなど、呼び出したいものを使用します。これにより、設計の柔軟性が最大になります。データモデル用の 1 つの場所、PurchaseOrders の保存/取得方法に関するビジネスロジック (コントローラー) 用の 1 つの場所、および実際に永続化される場所が 1 つあります。

score 0 · Accepted Answer

私の推論を説明しましょう。

クラスメソッド
基本原則: 持続性はクラスの動作であり、クラスメソッドであるべき 最初の問題: さまざまな DAO のセットをサポートする必要がある場合は、Factory を介してそれらを作成する必要があります。2 番目の問題: すべての永続化動作が特にクラスのインスタンスに関連しているわけではありません。たとえば、List メソッドと Search メソッドは、クラスではなくクラスリストを返し、インスタンスに依存しません。したがって、それらは基本的に静的メソッドです。

3 番目の問題: このクラスで継承をサポートしたい。そのため、永続化の詳細は親ごとに異なります。静的メソッドがある場合、それは問題になります。

それで、あなたはに進みます

コントローラー
の基本原則:永続化メソッドは単一のクラスに属していません。それらはより大きく、したがって
分離する必要があります。懸念の分離が再び必要になるため、DAO が必要です。これは Utility クラスなので、メソッドはすべて基本的にstaticです。
最初の問題: 複数の永続化方法をサポートする場合は、DAO を作成するための Factory が必要です。
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...

score -1 · Accepted Answer

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

ここで問題は、POクラスとDAOクラス間の相互作用を管理するために3番目のクラス（コントローラー）が必要ですか？それは、DAOクラスへのインターフェイスをどれだけ一般的にできるかにかかっていると思います。DAOインターフェイスが一般的で、別のストレージメカニズムを使用してプラグインの代替を記述できるが、インターフェイスを変更しない場合は、POクラスがDAOと対話できるようにします。そうでない場合は、コントローラークラスを作成します。

考えるべきもう1つのことは、構造の残りの部分です。保存/ロードはどこから開始されますか？POの多くの操作（保存、ロード、印刷、顧客への送信）を行う場合は、機能をPOクラスに統合するのではなく、これらすべてを実行するコントローラーを使用するのが理にかなっています。。これにより、POクラスを変更せずにPO操作を追加できるという利点があります。

score -1 · Accepted Answer

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

score -1 · Accepted Answer

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

design-patterns - クラスデータの責任

8 に答える 8

Related

Reference