このトピックにはかなりの数があることは知っていますが、私の質問に完全に答えるものを見つけることができなかったようです. Service->DAO->Low level code architecture を使用するように言われました。Service クラスの正確な役割を理解するのに苦労しています。1 つの Service クラスは Book DAO とユーザー DAO で機能しますか? それぞれに Service クラスを用意し、Service クラスに DAO と通信させ、結果の文字列を取得して Book クラスと User クラスに格納し、そのオブジェクトを Controller に送り返します。私の考えでは、Service クラスはすべての作業を他のクラスに委任する高レベルのクラスです。ご協力いただきありがとうございます。
質問する
260 次
2 に答える
0
サービスクラスは抽象化のレイヤーとして機能している可能性があるため、DAOまたはデータレイヤーは「ビジネスレイヤー」から隠されています。
サービスは、機能を実行するために複数の DAO と対話する場合があります。この場合、サービスは Facade パターンのように動作し、必要な機能を実行するための DAO との通信の複雑さを隠します。
この種のパターンは、ビジネス ロジックが下位レベルのプロトコルから分離されているという点で、ポートとアダプター、または六角形のアーキテクチャで見られます。
于 2013-10-21T01:41:11.090 に答える
0
サービス層と呼ばれるサービス クラスの集合は、エンタープライズ アプリケーションのビジネス ロジックの実行を担当します。サービス クラスは通常、DAO に直接マップされません。これは、サービス クラスが多数のドメイン オブジェクトを含む可能性があるビジネス オペレーションを表すためです。例として、注文の受理を担当するコードが、注文、顧客口座、金融口座、および在庫を表すオブジェクトと連携する必要がある注文送信プロセスがあります。
さまざまなビジネス オペレーションを異なるサービス クラスに分離することは、オペレーションの複雑さ、それらがどの程度密接に関連しているかなどに依存する設計上の決定です。一部の設計者は、各ビジネス オペレーションを本質的に個別のクラス (コマンド パターンと同様) にする必要があると判断するかもしれませんが、より豊富な種類のメソッドを備えたより包括的なインターフェイスを好む設計者もいます。
サービス層の概念は、すべてのビジネス ロジックが 1 つの場所に格納され、重複しないようにするために存在します。最新のシステムの多くは、Web アプリケーション (おそらく Spring MVC コントローラーを使用)、SOAP または REST インターフェース (おそらく Jersey を使用)、およびレガシー端末または他のシステム用の特殊なアダプターなど、バックエンドへのいくつかのインターフェースを備えています。これらのインターフェイスを共通のサービス層のすべてのアダプターにすることで、すべてのアダプターが一貫した方法で動作し、サービス層への変更がすべてのアクセス インターフェイスに適用されるようになります。
あなたの特定のケースでは、質問する必要があるため、おそらく単一のサービス オブジェクトで十分です。interfaceテストまたは将来のアップグレードのために実装を置き換えることができるように、すべてのサービスメソッドを個別にリストし、それにコード化することは常に良い考えです。
于 2013-10-21T01:49:15.097 に答える