DAOがControllerクラスから直接呼び出されること、およびModelクラスからDAOが呼び出されることに対するさまざまな引数を見てきました。実際、MVCパターンに従っている場合、コントローラーはDAOに結合されるべきではなく、Modelクラスに結合されるべきだと個人的に感じています内部からDAOを呼び出し、コントローラーがモデルクラスを呼び出す必要があります。理由は、Webアプリケーションからモデルクラスを切り離し、RESTサービスを使用するなどのさまざまな方法で機能を公開できるためです。モデルクラス。
コントローラーでDAO呼び出しを記述した場合、RESTサービスが機能を再利用することは不可能でしょうか?以下の両方のアプローチを要約しました。
アプローチ#1
public class CustomerController extends HttpServlet {
proctected void doPost(....) {
Customer customer = new Customer("xxxxx","23",1);
new CustomerDAO().save(customer);
}
}
アプローチ#2
public class CustomerController extends HttpServlet {
proctected void doPost(....) {
Customer customer = new Customer("xxxxx","23",1);
customer.save(customer);
}
}
public class Customer {
...........
private void save(Customer customer){
new CustomerDAO().save(customer);
}
}
注-
モデルの定義は次のとおりです。
モデル:モデルはアプリケーションドメインの動作とデータを管理し、その状態に関する情報の要求(通常はビューから)に応答し、状態を変更するための指示(通常はコントローラーから)に応答します。
イベント駆動型システムでは、モデルは、情報が変更されたときにオブザーバー(通常はビュー)に通知して、反応できるようにします。
#1または#2を多く使用しているので、これについて専門家の意見が必要です。
私の意見では、MVCパターンと3層アーキテクチャーを区別する必要があります。総括する:
3層アーキテクチャ:
MVCパターンは、上記のアーキテクチャのプレゼンテーション層で発生します(Webアプリケーションの場合)。
typical HTTPリクエストのライフサイクル:
モデルレイヤーから。
より正確には、サービスはドメインオブジェクトとストレージロジックの抽象化の間の相互作用を制御するため、モデルレイヤーに含まれています。
コントローラーはモデルレイヤーの状態の変更のみを担当します。 DAOは永続化メカニズムの一部です。これは、ドメインビジネスおよびアプリケーションロジックの一部を構成します。コントローラーでDAOとの相互作用を開始すると、ドメインロジックがプレゼンテーションレイヤーでリークされます。
公式のMVCパターンが何を要求するのかはわかりませんが、通常はコントローラーとDAOの間に「サービス」レイヤーを置きたいと思います。コントローラーは要求からデータをプルし、それを適切なサービスクラスに渡します。サービスクラスは、モデルクラスを返す1つ以上のDAOを呼び出す責任があります。これらのモデルクラスは、ビューレイヤーに送信するためにコントローラーに返送されます。複数のコントローラーが同じサービスレイヤーメソッドを利用できるため、サービスレイヤーを配置すると再利用に役立ちます。