关注存储库模式和实体框架3.5

Cra*_*aig 6 asp.net-mvc entity-framework separation-of-concerns repository-pattern

我想成为一个更好的开发者......

我正在做的事情:

  1. .Net MVC Framework 1.0
  2. 实体框架3.5

我一直在做一些阅读,我想我想做的是:

  1. 为域中的每个聚合创建存储库.例如,订单存储库将管理订单的OrderItems.
  2. 创建服务层以处理业务逻辑.每个存储库都有一个具有类似方法的相应服务对象.
  3. 在存储库和服务之间创建过去的DTO
  4. 可能会创建ViewModel,这是View要使用的类.

我有一个基础存储库接口,我的聚合存储库接口将实现...

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

我的订单存储库界面定义如下......随着我对这个学习练习的更多了解,可能还会有其他方法.

public interface IOrderRepository : IRepository<Order>
{
}
Run Code Online (Sandbox Code Playgroud)

我的服务类基本上定义为与存储库相同,除了每个服务实现包括业务逻辑.这些服务将在构造函数中使用一个存储库接口(在本练习中我还没有为IoC做好准备,但我相信这就是我最终要走的路).

  1. 存储库实现将使用Entity Framework从数据库推送和拉取.检索数据时; 这些方法只返回DTO而不是EF生成的对象
  2. 服务(因为我正在调用它们)将控制存储库并执行业务逻辑.您将在控制器中看到这些服务,即_orderService.GetById(1).
  3. 这是我开始翻转的地方并且可以使用一些反馈......我是否应该让我的服务类填充ViewModel类...我应该没有ViewModel类....也许这是从一种类型到另一种类型的过多映射?

我希望得到一些关于我关注问题的方向的反馈意见.

谢谢

red*_*ver 1

我认为您正在朝着存储库模式的正确方向前进。关于您有关 ViewModel 类的问题,我建议您使用将业务服务方法输出的输出转换为某些所需输出的方法。例如,您的 Order 业务服务可能有一个名为 的方法GetOrders()。使用自定义属性,您可以为其定义视图类类型。视图能够获取此方法的输出,可能将其与其他类型的数据连接起来,并将结果作为具有匿名类型的对象集合返回。在这种情况下,视图将采用IQueryable<Order>orIEnumerable<Order>作为输入并IList作为输出返回。

当您需要在客户端显示不同类型的数据视图时,此方法将为您提供很大帮助。我们已经在我们公司的框架中使用了与此方法类似(但更复杂)的方法。