2

私が取り組んでいるプロジェクトでは、JSF + Spring + Hibernate を使用しています。

これは、私がしばしば混乱してきた設計上の問題です。

現在、dao -> サービス -> ビュー -> コントローラーの「レイヤード」アプローチを含むプロジェクトを継承しています。

「コントローラー」層/層？現在、フロントエンドとやり取りするすべてのロジックとオブジェクトがあります。これを 2 つの層 / 層に分けるのが良い方法であると言われました。「コントローラー」層 / 層には、フロント エンドとやり取りするメソッド / オブジェクトのみが含まれ、2 番目の層 (bm?) にはすべてのビジネス ロジックが含まれます。コントローラによって使用されます。

1st.) コントローラをこのように分割する目的は何ですか?

2nd.) 現状のままで何か問題はありますか?

4

3 に答える 3

5

1st.) What would the purpose be of dividing up the controller in such a way?

でビジネス ロジックを処理する必要がありService Layerます。ビジネス エンティティを から分離する利点Controller/UI Layer:

  1. ビジネス エンティティを別のクライアント セクションで再利用できます。例 : Web ベースのアプリケーションを UI として開発している場合、後でデスクトップ UI も開発します。この場合Business Layer、複数の UI で操作を再利用できます。ビジネスレイヤーを使用して、Web サービスとして機能させることもできます。
  2. 分離されたビジネス オペレーションは管理が容易です。開発チームの誰かが UI コードがどのように機能するかを知らず、一部のビジネス ロジックのみを修正したい場合は、修正できます。

2nd.) Is there anything wrong with leaving it the way it currently is?

レイヤード アーキテクチャを初めて使用する場合は、必要なレイヤーを理解して実装するのに時間がかかるでしょう。時間枠とアプリケーションの要件によって異なります。アプリケーションで上記のポイントを使用する予定がある場合は、レイヤード アーキテクチャを使用するか、現在の実装を使用してください。

于 2012-08-18T05:20:24.660 に答える
2

ビューで使用されるサービス レイヤーを使用することをお勧めする理由を尋ねている場合、その答えは、多くの場合、特定のビューとは異なるアプリケーションの部分からサービスにアクセスしたいということです。

たとえば、最初は主に /order.xhtml ページで使用されていた注文を検証するロジックがあるとします。Service とそれに対応するオブジェクト (Order など) がビューに表示されていても、そのページに問題はありません。

しかし、バッチ ジョブから注文の検証を行う必要があります。その検証用のコードがビューに密接に結合されている場合、これは不可能または非常に困難であり、おそらく非常に扱いにくいものになります (PageContext一部のビジネス ロジックでたまたま JSP が必要になったため、JSP をモックしている人を見てきました)。

JAX-RS を介した外部 API、まったく異なるビュー (別のユーザーのページ、またはおそらくモバイル向けの UI) など、これが忍び寄る他の状況がかなりあります。

于 2012-08-17T22:30:48.563 に答える