0

ASP.Net MVC アプリケーション、モバイル アプリケーションなどで同じレイヤーを使用するために、Entity Framework (POCO エンティティ) を使用してレイヤード アーキテクチャ (すべてのレイヤーが同じマシン上にある) を設計しています。また、テスト容易性を維持するために...

UI レイヤー > サービス レイヤー > リポジトリ レイヤー > エンティティ フレームワーク > データベースを配置し、依存関係の挿入、レイヤーの抽象化、関心の分離を行います。

  • 2 つのメソッドがあるとします (Customer、Order はエンティティ クラスです)。これらのメソッドをどのレイヤーに配置する必要がありますか?:

    • public IList GetOrdersByCustomerId(int CustomerId) LINQ クエリを含みます。
      (リポジトリ層、またはサービス層?)
    • public void RequestAnOrderAndStartTheShipmentProcess(Customer CustomerEntity, Order OrderEntity) orderRepository.Add(OrderEntity)、shipmentRepository.Add(ShipmentEntity) などの挿入操作を行います...
      (別のビジネス ロジック層、またはサービス層?)

  • IOrderService インターフェイスと、依存性注入用の "OrderService : IOrderService" クラスがあります。インターフェイスとクラスは同じアセンブリに配置されますか、それとも別のアセンブリに配置する必要がありますか?

ありがとう

編集

ご回答有難うございます。しかし、この場合、次の 4 つの質問について考えるようになりました...
1. UI に DataAccess アセンブリへの参照がある場合、開発者は UI コードで DataAccess クラスに直接アクセスできますが、コード レビューを行うための余分な労力が発生するべきではありません。 (たとえば、チームにジュニア開発者がいる場合)?
2. リポジトリ層 (実際のクエリを実行する) とサービス層 (OrderRepository クラスで GetOrdersByCustomerId メソッドを呼び出す) の両方に GetOrdersByCustomerId メソッドが必要であると理解しましたが、正しいですか?
3. また、(ほぼ) すべてのテーブルを維持するために CRUD 操作を行う必要があります。また、現在のプロジェクトに 96 個のテーブルがあると考えてください (多すぎませんが、少なくもありません)。Add、Update、Delete メソッドが必要です。サービス層でも？それとも、サービス層でもっと「行動」について考える必要がありますか?
4. OrderRepository に GetOrdersByCustomerById、GetOrdersByStatus などのメソッドがある場合、それは DAO クラスのようなものではないでしょうか。

4

2 に答える 2

2

3 つのアセンブリ (レイヤー) を持つアーキテクチャを考えることができます。


サービス クラス (および RequestAnOrderAndStartTheShipmentProcess メソッド) を含むビジネス。ビジネス レイヤーにはすべてのコア ビジネス ルールが含まれるため、突然このレイヤーを完全に新しいレイヤーに交換したり、別のレイヤーを追加したりすることはほとんどありません。したがって、このアセンブリに OrderService と IOrderService の両方を保持します。また、POCO クラス (このように EF にこれらを自動生成させる) とリポジトリ インターフェイスをこのレイヤーに配置します。

DataAccess
これは、EF リポジトリの実装 (および GetOrdersByCustomerId メソッド) を保持する場所です。このアセンブリは、ビジネス アセンブリを参照します。これは、その層にあるリポジトリ インターフェイスを実装するためです。

UI
ここでは、DataAccess アセンブリからリポジトリをインスタンス化し、コンストラクター注入を使用してこれらをビジネス層のサービス クラスに注入します。したがって、このアセンブリには Business と DataAccess への参照があります。

このアーキテクチャを使用すると、ビジネス層が他の層から適切に分離され、単体テストが容易になります。依存性注入の詳細については、この回答を参照してください。

于 2012-05-22T18:50:24.350 に答える
1

私の意見（常に少し恣意的です）：

  1. 単一のエンティティ セットに対する典型的な指定された取得操作であるため、リポジトリ。
  2. サービス層。複数のエンティティで複数の操作を調整するためです。
  3. アセンブリを分離します。これにより、実装が既に含まれているアセンブリを参照することなく、他のアセンブリからインターフェイスの実装を追加できます。
于 2012-05-21T18:21:25.613 に答える