サービス層からのすべての呼び出しがビジネス層に送られ、データ層によって永続化される 3 層のアプリケーションがあります。各レイヤーのコンポーネントは、下のレイヤーのみを呼び出すことができます。
しかし、私たちは何百ものエンティティを持ち、crud 操作に関連する多くのサービスを持っているため、私たちのチームでは多くの論争が発生しました.
一部の人は、保守と開発の容易さのために、crud 操作を実行し、ビジネス層をバイパスするだけの crud サービスからデータ アクセスを呼び出す方がよいと考えています。
それどころか、ビジネス層の各エンティティのデータ アクセス用のラッパーを作成し、サービスからこれらのラッパーを呼び出す必要があり、サービスがデータ アクセス層を呼び出すことを許可しないという意見もあります。
あなたの考えでは、どちらの方法を取るべきですか? crud サービスがデータ アクセスを呼び出してビジネス レイヤーをバイパスしても問題ありませんか?
実行するビジネス ロジックがない場合、ビジネス レイヤーを強制する理由はありません。3 層アーキテクチャは難解なプロトコルではなく、ビジネス処理を想定して形成されたベスト プラクティスにすぎません。
現在のアプリケーションでは、ビジネス プロセスが関与していないときに、JSF コントローラから直接 DAO にアクセスすることがよくあります。このアイデアは、単純さが最も重要であるという考えを強調したJava チャンピオンによって与えられました 。
ビジネス ロジックの追加が必要になる可能性がある将来の変更が心配な場合。私はこの問題を次のように考えています。追加のビジネス ロジックは、データ アクセスを含め、とにかくビジネス レイヤーに追加されるため、ここでは違いはありません。
CRUD コードはたいてい非常に単純です。したがって、サービスの変更は、DAO から EJB への 1 回または 2 回の呼び出しを再ルーティングすることになります。これは単純なリファクタリングです。CRUD コード自体はそのまま残りますが、EJB にプッシュされます (別の簡単なリファクタリング)。
これは完璧ではありませんが、代替手段よりもIMOの方が優れています。つまり、空の間接レイヤーを使用します。これにより、何の役にも立たない複雑さが増します。ビジネス オブジェクトは、呼び出しを DAO に転送するだけです。
この場合に当てはまると思われる コードの匂いが 2 つあり ます。
ビジネス層の DA がコードの匂いだと言っているのではありません。私が言いたいのは、DAO をプロキシするだけのビジネス オブジェクトを持つことは臭いということです。複雑さについても同じです。独自の目的を果たさない追加のデータ構造/アーキテクチャ レイヤーです。アプリケーションには既に DAL が存在するようです。
考慮すべきもう 1 つの側面は、DAO を直接使用するサービスを開発者が目にするのはどれほど驚くべきことでしょうか? 5 つのサービスがあり、そのうちの 2 つが DAO に直接アクセスするのと、100 のサービスがあり、1 つのサービスのみが DAO に直接アクセスするのとは異なります。
最初のケースでは、コードの単純さが追加された概念の複雑さ (1 つのことに対して 2 つのコンセプト) を上回り、2 番目のケースでは、むしろビジネス層に固執したいと思います。別の方法では、一度だけでは大きすぎます。
私の意見では、ビジネス レイヤーをバイパスして CRUD サービスを呼び出すと、機能が増えるにつれて、現在のサービス レイヤーがビジネス レイヤーに変換され始めます。したがって、問題がなければ、サービス層もビジネス層として機能します。
ほとんどの場合、エンティティを扱います。たとえば、1 回の更新で多くのデータ レイヤーの crud 呼び出しが発生する可能性があります。この目的には、ビジネス層が推奨されます。ビジネス レイヤーは、必要に応じてビジネス ルールを実行したり、他のビジネス サービスをキャッシュしたり呼び出したりする場所です。これにより、上位層がシンプルに保たれ、通過します。