我对存储库中定义的内容的限制以及要留给服务的内容感到困惑.存储库是否应仅创建与数据库中的表匹配的简单实体,还是可以使用这些实体的组合创建复杂的自定义对象?
换句话说:服务是否应该在存储库上进行各种Linq to SQL查询?或者是否应在存储库中预定义所有查询,业务逻辑只是决定调用哪种方法?
您实际上在这里提出了一个问题,目前正在开发人员社区中进行大量讨论 - 请参阅后续评论我的存储库是否应该公开IQueryable?
存储库可以 - 并且应该 - 创建包含多个关联实体的复杂组合对象.在域驱动设计中,这些被称为聚合 - 相关对象的集合被组织成一些有凝聚力的结构.您的代码没有调用GetCustomer()
,GetOrdersForCustomer()
,GetInvoicesForCustomer()
分别-你只需要调用myCustomerRepository.Load(customerId)
,你会得到回来已经实例化的特性的深厚的客户对象.我还要补充一点,如果你是基于特定的数据库表返回单个对象,那么这是一个非常有效的方法,但它不是一个真正的仓库本身 -它只是一个数据访问层.
一方面,有一个令人信服的论点,即Linq-to-SQL对象具有"智能"属性和延迟执行(即在实际使用之前不加载Customer.Orders)是存储库模式的完全有效的实现,因为您实际上并没有运行数据库代码,所以您正在运行LINQ语句(然后由底层LINQ提供程序将其转换为DB代码)
另一方面,正如Matt Briggs的帖子指出的那样,L2S与你的数据库结构(每个表一个类)紧密耦合,并且有局限性(例如,没有多少映射) - 你可能最好使用L2S 在存储库中进行数据访问,然后将L2S对象映射到您自己的域模型对象上并返回这些对象.