2

プロジェクト構造については次のとおりです。これらはすべて個別のプロジェクトです。そのようにするように言われたので、私の選択ではありません。

CORE 
  --Self Explanitory
DATA 
  --Contains EF 4.1 EDMX, POCO's Generic Repository Interface
DATAMapping
  --Contains Generic Repository
Services
  -- Contains nothing at the moment
MVC 3 Application
  -- Self Explanitory

これが私の質問です。コントローラーをダイエットに保つことがベストプラクティスであり、モデル/ビューモデルは愚かであるべきであるため、プロジェクト構造のサービスレイヤー部分を導入することを読んでいます。今の実際の質問; これは良いアプローチですか、それとも自分のためにあまりにも多くの作業を作成していますか?

したがって、製品やカテゴリ、またはその他のエンティティに対していくつかの CRUD 操作を行いたい場合、リポジトリはサービス層/ビジネス ロジック層からインスタンス化する必要がありますか?

いくつかの入力をお願いします??

4

1 に答える 1

3

個人的には、サービス レイヤーが CRUD 操作用の汎用リポジトリと抽象リポジトリのみを参照しています。たとえば、サービス層コンストラクターは次のようになります。

public class MyService: IMyService
{
    private readonly IFooRepository _fooRepo;
    private readonly IBarRepository _barRepo;

    public MyService(IFooRepository fooRepo, IBarRepository barRepo)
    {
        _fooRepo = fooRepo;
        _barRepo = barRepo;
    }

    public OutputModel SomeBusinessMethod(InputModel input)
    {
        // ... use CRUD methods on _fooRepo and _barRepo to define a business operation
    }
}

コントローラは単純に をIMyServiceコンストラクタに取り込んで、ビジネス オペレーションを使用します。

次に、選択した依存性注入フレームワークによってすべてが接続されます。

于 2011-04-02T15:18:03.897 に答える