2

プレゼンテーション層がサービス層と通信し、サービス層がビジネス層と通信する 3 層アプリケーションを開発しています。ビジネス層はデータベースにアクセスできます。現在、テーブルの CRUD 操作を保持するためにビジネス レイヤーを実装しています。サービス層とビジネス層でメソッドを整理することに関して、いくつかの疑問があります。

  • まず、サービス層のメソッドをどのようにグループ化する必要がありますか? ページに必要なすべてのデータがサービスのメソッドによって提供される場合、ページに基づいてメソッドをグループ化する必要があります。それとも、複数回のサービス呼び出しでページ データを取得する必要がありますか?

  • もう 1 つの懸念事項は、ビジネス レイヤーでのメソッドの編成に関するものです。サービス レイヤーのメソッドについては、対応するメソッドをビジネス レイヤーで実装する必要があるようです。このロジックに従うと、サービス層のメソッドはダミーのように動作し、承認と検証のみを処理します。例: 2 つのテーブルの結合から得られるデータをフェッチする場合、サービス レイヤーで 2 つのテーブルをフェッチしてからサービス レイヤーで結合を実行するか、ビジネス レイヤーで同じことを行う関数を用意する必要があります。サービス層とビジネス層の間のデータ転送を本質的に減らします。

4

2 に答える 2

1

DTOパターンを見てください。DTO パターンを使用すると、バックエンド サービスへの呼び出しの数を最小限に抑えることができます。また、指定された DTO は複数の BO にマップできます。UI を設定するには、データ要件に基づいて DTO を設計する必要があります。

于 2011-11-16T07:58:03.790 に答える
0

私が望んでいたのは、REST アーキテクチャに従うことだったようです。つまり、サービス層とプレゼンテーション層の間のインターフェイスを統一する必要があります。サービス層は承認を処理し、すべての呼び出しをビジネス層に委任します。ビジネス層では、SL に送信する前に XML、JSON などにシリアル化された DTO を保持します。私が本当に役立ったのは、REST の記事に目を通し、それらを詳細に調査したことです。

于 2011-11-30T19:09:20.730 に答える