javaweb ビジネス層の書き方

ビジネス層

サービス層: 対応するDaoデータベース操作を参照し、必要なコード(単純な判定など)を記述できます。

サービス層は、さまざまな DAO ビジネス オペレーションを呼び出します (たとえば、ビジネスが追加されてから変更される場合など)。次に、サービス層でのデータ変換と論理判断を含む dao の追加操作と変更操作をそれぞれ呼び出します。dao は追加、削除、変更、確認を行うだけです。また、トランザクションは通常、サービス層に配置されます。
サービス層と DAO 層はどちらもデータベース上で動作する可能性があり、その具体的な違いは次のとおりです。

dao とサービスは

# に対応します。 ## 通常、Hibernate DAO は 1 つの POJO オブジェクトのみを操作するため、1 つの DAO は 1 つの POJO オブジェクトに対応します。サービス層は、複数の POJO オブジェクト (つまり、複数のテーブルに対するデータ操作) を処理するときのトランザクション管理 (宣言的トランザクション管理) を目的としています。サービス層 (そのインターフェースの実装クラス) には、データ操作を完了するために複数の DAO オブジェクトが注入されます。

サービスの有無
この点に関する私の意見は正しくないかもしれませんが、ビジネス層を構築するために私の頭の中に 2 つのモデルがあります: モード 1 はサービス DAO です。つまり、DAO は CRUD および同様の単純な操作 (ファンクション ポイントと呼ばれ、ビジネス ロジックは含まれません) のみを実行します。サービスは、DAO で 1 つ以上のファンクション ポイントを呼び出すことによってビジネス ロジックに結合されます。量は機能モジュールによって決定される必要があります。
このモデルでは、ビジネス ロジックはサービスに配置され、トランザクションの境界もサービスで制御される必要があります。もちろん、サービスでトランザクションを直接制御すると、ビジネス ロジック以外のコードが導入されます。幸いなことに、Spring のAOP はこの問題を解決できます。これは Spring を導入する理由の 1 つでもあります。
欠点について言えば、一部のオブジェクトの操作が単純な CRUD であり、サービス層が面倒に見えることです。

モード 2 はサービス BO で、BO = DAO ビジネス メソッドで、元の DAO に基づいてビジネス メソッドを追加して BO オブジェクトを形成します。 BO のビジネス メソッドは 1 つのエンティティ オブジェクトを対象とすることが多いため、複数のエンティティ オブジェクトにまたがる必要がある場合は、メソッドを Service に配置する必要があることに注意してください。

たとえば、

単純な銀行口座管理システムは、パスワードの変更を含めることができる口座 BO オブジェクトを作成します。マネーやその他のビジネス メソッド (これらのメソッドが 1 つのアカウント オブジェクトに対してのみ動作することは、難しくありません)。次に、転送メソッドを追加する必要があります。これは Service に配置する必要があります。

ここでの Service と BO の関係は何ですか?別の例:

国の行政機関を例に挙げます。穀物局は穀物の集荷、種子の販売などを担当し、建設省は土地販売の承認や道路建設を担当します。 、など、これらはすべて管理部門内の事項です。ある場所で突然洪水が発生し、災害救援の際、穀物局は倉庫を開けて穀物を放出しなければならず、建設省は仮設住宅を建てる必要があるが、両部門の連携はどうするのか。特別災害救援委員会を設立し、これら 2 つの部分からリソースを配分する必要があります。ここの 2 つの部分は BO であり、災害救援委員会は Service です。言いたいことが正確に表現できたかわかりませんが（笑）。モード 1 にはサービスと DAO を分割する際の明確な境界がありますが、不要なコードがいくつか発生します。モード 2 の分割は比較的複雑ですが、コーディング効率を向上させることができます。

もちろん、小規模なアプリケーションでは、サービスなしで DAO または BO を使用することもできます。

Service と DAO の間にインターフェイスがあるかどうか

インターフェイスはコントラクトであり、複数の実装を持つことができます。したがって、インターフェイスの有無は、特定の実装を多様化する必要があるかどうかによって異なります。 DAO またはサービスの実装が 1 つだけであると判断された場合、インターフェイスを抽象化する意味はほとんどありません。ただし、一部の大規模なアプリケーションでは、DAO とサービスの複数の実装が必要な場合があります (上記の例のアカウント DAO など、Hibernate 実装、CMP 実装、および JDO 実装が必要な場合があります)。上位レベルでは、インターフェイスを使用する必要があります。

特定の実装クラスの作成プロセスを非表示にする 2 つの方法があります: 1 つは実用的なファクトリ メソッドで、これには大量のコード (DAO とサービスごとに 1 つのファクトリ) が必要になります。 2 つ目は、Spring の IoC を使用して、追加のコードを記述せずに依存関係注入を実装することであり、これが Spring を導入する 2 つ目の理由でもあります。

以上がjavaweb ビジネス層の書き方の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。