すべてのテーブルプロパティをUOWクラス（汎用リポジトリパターン）にするとよいですか？

Question

私はAsp.net MVCプロジェクトに取り組んでいます。私はlinkに続いて汎用リポジトリを作成しました。

public class UnitOfWork : IDisposable 
{ 

    private LeisureEntities context = new LeisureEntities(); 
    private IGenericInterface<cust_order> _customerOrderRepository; 
    private IGenericInterface<tblCustomer> _customerMasterRepository; 


    public IGenericInterface<cust_order> CustomerOrderRepository 
    { 
     get 
     { 
      return _customerOrderRepository = new GenericRepository<cust_order>(context); 
     } 
    } 

    public IGenericInterface<tblCustomer> CustomerMasterRepository 
    { 
     get 
     { 
      return _customerMasterRepository = new GenericRepository<tblCustomer>(context); 
     } 
    } 

    public void SaveChanges() 
    { 
     context.SaveChanges(); 
    } 



    private bool disposed = false; 

    protected virtual void Dispose(bool disposing) 
    { 
     if (!this.disposed) 
     { 
      if (disposing) 
      { 
       context.Dispose(); 
      } 
     } 
     this.disposed = true; 
    } 

    public void Dispose() 
    { 
     Dispose(true); 
     GC.SuppressFinalize(this); 
    } 
} 

UOWクラスのすべてのリポジトリをプロパティとして宣言し、このUOWをコントローラまたはサービス層で直接使用できますか。つまり、DALの1つの汎用リポジトリクラスと1つのUOWクラスには、dbテーブルのすべてのプロパティを持つクラスが2つしかありません。

私はテーブルごとに別々のUOWを作成する必要があります。

私はデータベースの最初のアプローチを使用しています。

お勧めします。

Answer 1

いいえ！すべてのエンティティに対してUOWを作成するアプローチは非常に悪いアプローチです。しかし、データを抽象化するという考えは良いです。

私はすべてのエンティティにGenericRepositoryを使用しています。これは、データを抽象化するための最良の方法です。すべてのリポジトリは、特定のエンティティの操作を担当します。

次に、サービスですべてのビジネスロジックを抽出します。>そのようにして、ビジネスロジックはSOLIDの原則に従ってクラスライブラリプロジェクトで分離されます。

すべてのオブジェクトには、必要なものがあります。私はあなたのアーキテクチャをチェックして再利用するオープンソースのgitリポジトリを提供します。 Dataフォルダを見てください。

唯一の違いは、データベースの最初のアプローチを使用していることです。解決策は、部分クラスでdbコンテキストを拡張することです。

これを見てください。これは、ベストプラクティスに従うことによって行われます。それは非常に簡単に拡張することができます。 .........................................

Mvc eshop architecture

.................................................. .................................................. ........................

はい、アーキテクチャーは少し抽象的ですが、最初の視野からは複雑すぎると思いますが、これはあなたのスーパーを解決します将来起こる前の多くの建築上の問題。私は、最も簡単なサービス/ビジネスロジック/をあなたに貼り付けて、あなたが望むように、それが何で、なぜそれがすべてであるかをより明確に理解できるようにします。

using Eshop.Data.Repositories; 

namespace Eshop.Services.Data 
{ 
using Contracts; 
using Eshop.Data.Models; 
using System.Linq; 

public class CategoriesService : ICategoriesService 
{ 
    private IRepository<Category> repo; 

    public CategoriesService(IRepository<Category> repo) 
    { 
     this.repo = repo; 
    } 

    public IQueryable<Category> GetAllCategories() 
    { 
     var categoriesToReturn = this.repo.All().Where(x => x.IsDeleted != true); 
     return categoriesToReturn; 
    } 

} 

すべてのサービスで、IQueryableを返してクエリを混雑させる必要があります。あなたのコントローラーでは、コントローラーがあなたのデータについて何も知らなかったサービスとWebパーツを注入します。 NinjectやAutoFakを使って依存関係を逆転させてサービスを注入するときは、それらのメソッドを使用してコントローラのクエリ結果を具体化します。ホームコントローラーでサービスをどのように注入するのかを見ることができます。あなたが行うことができる最も良いことは、あなたのビューモデルにAutomapperを使用してプロパティを自動マッピングすることです。この場合、コントローラは清潔に保たれ、数行のコードが残っています。彼らは要求をキャッシュし、データを取得してビューに渡すという義務を果たします。これがあなたに役立つことを願っています。このアプローチを使うと、すばやく作業しているものを簡単にサポートし、変更することができる大きな、大きなプロジェクトを作成できます。データベースを簡単に変更したり、リポジトリ内にメソッドを追加したり、他のカスタムアクションを追加することができます。たとえば、IDでクエリを実行したときに変更されたすべてのデータにフラグを設定したい場合は、 GenericRepositoryとこのフラグを1行で追加してください:)