我对在存储库中定义的内容以及留给服务的内容的限制感到困惑。存储库应该只创建与数据库中的表匹配的简单实体，还是可以创建具有这些实体组合的复杂自定义对象？
换句话说:服务是否应该在存储库上进行各种 Linq to SQL 查询？还是应该在存储库中预定义所有查询，而业务逻辑只需决定调用哪个方法？
最佳答案
您实际上在这里提出了一个问题，该问题目前在开发者社区中引起了很多讨论 - 请参阅对 Should my repository expose IQueryable? 的后续评论。
存储库可以并且应该创建包含多个关联实体的复杂组合对象。在领域驱动设计中，这些被称为 骨料 - 组织成某种内聚结构的关联对象的集合。您的代码不必调用 GetCustomer() , GetOrdersForCustomer() , GetInvoicesForCustomer()分开 - 您只需调用 myCustomerRepository.Load(customerId) ，然后您将返回一个具有已实例化这些属性的深层客户对象。我还应该补充一点，如果您基于特定的数据库表返回单个对象，那么这是一种完全有效的方法，但它并不是真正的存储库——它只是一个数据访问层。
一方面，有一个令人信服的论点，即具有“智能”属性和延迟执行(即在您实际使用之前不加载 Customer.Orders)的 Linq-to-SQL 对象是存储库模式的完全有效实现，因为您实际上并没有运行数据库代码，所以您正在运行 LINQ 语句(然后由底层 LINQ 提供程序将其转换为 DB 代码)
另一方面，正如 Matt Briggs 的帖子所指出的，L2S 与您的数据库结构紧密耦合(每个表一个类)并且有局限性(例如，没有多对多映射) - 您最好使用 L2S用于数据访问在 内您的存储库，然后将 L2S 对象映射到您自己的域模型对象并返回这些对象。
关于asp.net-mvc - MVC : Repositories and Services，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/444694/