JSF の MVC 環境での私のアプローチが最善の方法であるかどうかはわかりません。私は JSF を最大限に活用しようとしているので、サービス層 (または MVC 用語で言えばモデル) を「設計」する方法を知りたいです。
View-Controller の比率が 1 対 1 であることはわかっています (例外は除外されます)。では、サービス層をどのように設計すればよいでしょうか? 1 つの大きなサービスを使用する必要がありますか (そうは思わないでください)。そうでない場合、何に基づいてサービスを分割する必要がありますか?
私のサービスはBean（MVC用語ではコントローラー）から呼び出され、必要に応じてサービス自体がJPAを使用してDAOを呼び出すことに注意してください。
前もって感謝します
サービス層 (ビジネス モデル) は、メイン エンティティ (データ モデル) を中心に設計する必要があります。たとえば、 UserServicefor User、ProductServicefor Product、OrderServiceforOrderなど。1 つの巨大なサービス クラスなどを絶対に持つべきではありません。それは極端な密結合です。
サービス層 API 自体については、Java EE 6 は EJB 3.1 をサービス層 API として提供します。J2EE の暗黒の時代、EJB 2.0 での開発が難しかった昔、Spring はサービス層 API としてより頻繁に使用されていました。現在でも使用している人もいますが、Java EE 6 には Spring から学んだ素晴らしい教訓がすべて組み込まれているため、不要になりました。EJB (および JPA) は、Tomcat などのベアボーン サーブレット コンテナでは使用できないことに注意してください。たとえば、その上に OpenEJB をインストールする (または単に TomEE にアップグレードする) 必要があります。
サービス レイヤー API の選択に関係なく、ビジネス ジョブを完全にサービス レイヤーで実行することにより、JSF バッキング Bean (アクション) リスナー メソッドをできるだけ滑らかに保つことが最善です。サービス層自体にはJSF 依存関係がないことに注意してください。javax.faces.*そのため、サービス層コードでの(間接的な) 直接インポートは、設計が悪いことを示しています。特定のコード行をバッキング Bean に保持する必要があります (通常は、サービス呼び出しの結果に応じて faces メッセージを追加するコードです)。このようにして、サービス層は、JAX-RS や単純なサーブレットなどの他のフロント エンドでも再利用できます。
Java EE アプリケーションにおけるサービス層の主な利点は、コンテナー管理トランザクションの可用性であることを理解する必要があります。EJBでの 1 つのサービス メソッド呼び出しは、@Stateless実質的に 1 つの DB トランザクションとしてカウントされます。@PersistenceContext EntityManagerそのため、サービス メソッド呼び出しによって呼び出されたDAO 操作のいずれかで例外が発生した場合、完全なロールバックがトリガーされます。このようにして、たとえば最初の DB 操作クエリは成功したが、2 番目のクエリは成功しなかったため、ダーティ DB 状態ではなくクリーン DB 状態になります。
アプリにエンティティがほとんどない場合、サービスとモデル エンティティの 1:1 の比率は悪くないかもしれません。しかし、大きなアプリだとサービスが多すぎます。
サービスの数は、設計しているアプリのユース ケースによって異なります。分析フェーズでそれらを特定したら、機能に応じていくつかのグループにグループ化する必要があります。ユースケースの各グループはサービスになり、各ユースケースはそのサービスのメソッドになります。各サービスは、複数のモデル エンティティを管理できます (また、その機能を実行するために必要な DAO をサービスに注入する必要があります)。通常、サービスのユース ケースは、モデルのクラス図で相互に関連付けられたモデル エンティティを管理します。サービスは、「最大凝集力/最小結合」の優れた実践に従う場合があります。
DAO とモデル エンティティの比率は 1:1 です。各 DAO は、そのエンティティの CRUD 操作とクエリを実行します。メソッドが 2 つの関連エンティティをクエリする必要がある場合は、ビジネス コンセプトに応じて、より適切な DAO に配置します。
JSF プレゼンテーション レイヤーでは、ページとコントローラーの比率が 1:1 ではありません。これは、コントローラーが多すぎるためです。各サービスのユース ケースを実行するために必要なすべてのページを 1 つのコントローラーにグループ化します。したがって、コントローラーとサービスの比率は 1:1 であり、ページがユース ケースを実行するコントローラーに各サービスを挿入します。
もちろん、これらは一般原則です。アプリでそれらを壊した特定のケースがいくつかあるかもしれませんが、それらはほとんどありません.
サービスとコントローラーは多すぎないかもしれませんが、ロジックとフィールドが多すぎるため、少なすぎてもいけません。妥協をしなければなりません。