Linq 2 SQL-如何设计具有实体继承的正确存储库，控制器和视图模型流

如何解决Linq 2 SQL-如何设计具有实体继承的正确存储库，控制器和视图模型流

|| 问题：我想知道人们在ORM中使用实体继承（在这种情况下为带有MVC .NET的LINQ 2 SQL）时，人们将实现哪种类型的存储库和控制器设计/工作流程。 我有一个非常简单的层次结构，其中Clothing类（具体）从Product（抽象类）继承。但是，这使设计相当复杂。为Product的每个具体实现创建一个存储库类是愚蠢的，因此我将Product用作\'Product \'存储库中的参数类型和返回类型。 \“但是，因此，我必须将Product类型转换为Product的具体实现（在从存储库请求之前或之后）。 我注意到的另一件事是，即使我确定要转换为正确的类型，也必须定义视图模型以传递给Product的每个具体实现的视图。 如果这是需要做的，那就做吧，但是我对其他人的想法和/或经验感兴趣。     

解决方法

        为了便于讨论，我们假设您的存储库界面如下所示：

 public interface IRepository<T>{
     T GetById(int id);
     IQueryable<T> All();
     void Add(T entity);
     void Remove(T entity);
 }

而且，尽管您没必要为每种“ 1”类型实现存储库是正确的，但是您可以创建一个通用包装器类来实现接口，就好像它是专用存储库一样。例如，

 public class RepositoryWrapper<T,TBase> : IRepository<T> {
     where T: TBase

     private readonly IRepository<TBase> _repository;
     public RepositoryWrapper(IRepository<TBase> repository){
           _repository = repository;
     }


     public T GetById(int id){
          return (T)_repository.GetById(id);
     }

     public IQueryable<T> All(){
          return _repository.All().OfType<T>();     
     }


     public void Add(T entity){
          _repository.Add(entity);
     }
     public void Remove(T entity){
          _repository.Remove(entity);
     }
 }

您的用例为3，可以通过扩展方法简化创建过程，例如：

public static class SubRepositories{
   public static IRepository<TDerived> GetSubClassRepository<TBase,TDerived>(this IRepository<TBase> repository)
   where TDerived: TBase
   {
       return new RepositoryWrapper<TDerived,TBase>(repository);
   }
}

现在，就视图模型而言，在将其传递到控制器中时，无需指定视图模型的确切类型。一种替代方法是使用模板根据ModelMetadata自动确定要呈现的视图的类型。     ,        这听起来很接近您的问题： .NET中的存储库模式和继承     ,        我正在MVC应用程序中使用Linq to Sql，并且具有一些表继承来表示\“ floor \”中的项目。我有一个基本的“表”，还有2个表链接到基本表，然后扩展基本表并添加自己的列。 对我来说，因为我的子表与基本表的偏差不大，所以我创建了一个数据库视图，该视图返回所有基本表列以及派生表中的关键额外列以及一个“类型”识别它们是什么。然后，我的存储库与此数据库视图一起使用。 作为一种方法，这可能对您很有用，这取决于您拥有多少个子类型，它们如何不同以及您的需求。否则，@ smartcaveman提出了一个很好的建议。