6

私はより良い開発者になろうとしています...

私が取り組んでいるもの：

  1. .Net MVC Framework 1.0
  2. Entity Framework 3.5

私はいくつかの読書をしてきました、そして私がしたいことは次のとおりだと思います：

  1. ドメイン内の各アグリゲートのリポジトリを作成します。たとえば、Orderリポジトリは、OrderのOrderItemを管理します。
  2. ビジネスロジックを処理するサービスレイヤーを作成します。各リポジトリには、同様のメソッドを持つ対応するサービスオブジェクトがあります。
  3. リポジトリとサービスの間を通過するDTOを作成します
  4. おそらく、ビューが使用するクラスであるViewModelを作成します。

集約リポジトリインターフェイスが実装するベースリポジトリインターフェイスがあります...

public interface IRepository<T>
    {
        IEnumerable<T> ListAll();
        T GetById(int id);
        bool Add(T entity);
        bool Remove(T entity);
    }

私の注文リポジトリのインターフェースは次のように定義されています...この学習演習にさらに取り組むにつれて、追加のメソッドが存在する可能性があります。

public interface IOrderRepository : IRepository<Order>
{
}

私のサービスクラスは、各サービス実装にビジネスロジックが含まれていることを除いて、基本的にリポジトリと同じように定義されています。サービスはコンストラクターでリポジトリーインターフェースを取ります（この演習ではIoCの準備ができていませんが、それが最終的にはそこにあると信じています）。

  1. リポジトリの実装は、EntityFrameworkを使用してデータベースからプッシュおよびプルします。データを取得するとき。メソッドはDTOのみを返し、EFで生成されたオブジェクトは返しません
  2. サービス（私はそれらを呼んでいます）はリポジトリを制御し、ビジネスロジックを実行します。サービスは、コントローラーに表示されるもの、つまり_orderService.GetById（1）です。
  3. ここでフリップフロップを開始し、フィードバックを使用できます...サービスクラスにViewModelクラスを設定させる必要があります... ViewModelクラスを持たない必要があります...多分、あるタイプから別のタイプへのマッピングが多すぎますか？

関心の分離に関して、私が向かっている方向性についてフィードバックをもらいたいと思います。

ありがとう

4

1 に答える 1

1

あなたはリポジトリパターンについて正しい方向に向かっていると思います。ViewModelクラスに関する質問については、ビジネスサービスメソッドの出力をいくつかの目的の出力に変換するものを使用することをお勧めします。たとえば、Orderビジネスサービスに。というメソッドがあるとしGetOrders()ます。カスタム属性を使用して、そのビュークラスタイプを定義できます。ビューはこのメソッドの出力を取得でき、場合によっては他の種類のデータと結合して、匿名型のオブジェクトのコレクションとして結果を返します。この場合、ビューはIQueryable<Order>またはIEnumerable<Order>を入力として受け取り、出力として返しますIList。

この方法は、クライアント側でデータのさまざまな種類のビューを表示する必要がある場合に非常に役立ちます。当社のフレームワークでは、この方法に似た（しかしより複雑な）ものをすでに利用しています。

于 2009-11-23T03:29:46.053 に答える