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

时间:2009-11-23 03:13:36

标签: asp.net-mvc entity-framework repository-pattern separation-of-concerns

我正努力成为更好的开发者......

我正在与之合作:

  1. .Net MVC Framework 1.0
  2. 实体框架3.5
  3. 我一直在做一些阅读,我想我想做的是:

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

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

        由于

1 个答案:

答案 0 :(得分:1)

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

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