4

サービス層に検証コードを配置するように言っている本や記事の例をたくさん見てきました。ドメイン オブジェクトを「ダム」(別名、純粋な POCO) に保ち、ドメイン オブジェクトがサービス層で行う可能性のあるすべての検証を処理します。

サービス層は、見かけ上（または少なくともそうである可能性があります）、非常に多くの責任を負っています。ユーザー認証、ロール認証、IoC の依存関係オブジェクトのスクリプト作成 (ロガー、エラー ハンドラーなど)、ドメイン オブジェクトのスクリプト作成、リポジトリのスクリプト作成、およびリポジトリとの間でのドメイン オブジェクトの受け渡し...

サービス層でこれらすべてのルールを作成することは、ドメイン オブジェクトに重大な脅威をもたらしませんか? たとえば、一部のプログラマーがドメイン オブジェクトに対して直接消費するコードを記述し、サービス層を完全にバイパスすることを決定した場合はどうなるでしょうか? それは悪いことですが、信じられる状況です。

すべてのドメイン オブジェクトの検証を含め、サービス層に多くの責任を負わせようとしている場合、誰かがそれらを直接スクリプト化しようとしたときに、ドメイン オブジェクトを「保護」する方法はありますか? たとえば、何らかの方法でドメイン オブジェクトが特定のクライアント (この場合はサービス層?) によって使用されていない可能性があります。

優れた設計とは、ドメイン オブジェクトが、誰が呼び出しているのか、どのように呼び出されているのかについて何も知らなくてもよいと私に思わせるものです。

ドメイン オブジェクトを「ロックダウン」する方法がない場合、ドメイン オブジェクトの検証をサービス レイヤーに配置することを提案する記事や書籍が非常に多いのはなぜですか? 防御的なプログラミングの立場を取ることで、ドメイン オブジェクトを防弾となるように構築し、UI と BAL/DAL の間で要求を転送および受信するための単純なコード レイヤーとしてサービス レイヤーに依存する必要があると想像できます。

サービス層を迂回した人々によるドメイン オブジェクトの「悪用」について、実際のプロジェクトで経験した人はいますか?

4

2 に答える 2

2

POCOの目的を誤解しているかもしれません。私が理解しているように、POCO は、プロパティと属性のみを持つ貧血ドメイン オブジェクトではありません。むしろ、POCO は単にフレームワークや複雑な継承モデルに関連付けられていません。オブジェクトは柔軟で、ドメイン内での役割のみに関心があります。

于 2011-02-25T18:30:05.357 に答える
1

これらは 2 つの異なる設計哲学です。リッチ ドメイン モデルと貧血ドメイン モデル。

短い答えはイエスです。ドメイン オブジェクトへの直接アクセスを防ぐことができます。

いくつかのテクニックを使用してこれを行うことができます。

1) public メソッドのみを getter にするだけで、公開されているすべてのドメイン オブジェクトを不変 (つまり、データを変更できない) にすることができます。オブジェクトを変更するすべてのメソッドを保護またはパッケージ プライベートにすることができるため、正しくパッケージ化されたサービスのみがそれらにアクセスできます (少なくとも Java では)
2) 個別のクラスのみを外部開発者に公開できます。あなたが渡すPersonInfoクラスを持つことができます。それは情報を含むだけです。
3) 首尾一貫した API をアプリの消費者に公開する必要があります。基本的に、それらがサービス層をバイパスするのを防ぎます。

于 2011-02-24T18:01:12.380 に答える