在我们的Web应用程序中，我们有具有CRUD操作和通用查找程序功能的存储库，例如userRepository.Get(u => u.Username == someString)。
UserRepository只返回User个对象。
但是，如果我有一个复杂的查询在Table1，Table2和Table3之间进行连接并返回包含这3个表中某些属性的CustomObject，那该怎么办？ / p>
我应该将这些查询放在服务层吗？ 存储库是否只包含基本的CRUD和finder函数并返回基本实体对象而没有其他内容？我问，因为有些人告诉我，服务层中不应该有任何疑问......
答案 0 :(得分：1)
我可能会创建一个类型CustomObjectRepository，它封装表的连接并仅返回CustomObject个。具体如何实现通用查找器功能取决于您使用的ORM类型（对于EF来说它将是微不足道的，复杂但如果您进行手动映射则根本不可能）。
答案 1 :(得分：1)
您可以拥有一个面向业务逻辑视图的存储库，该存储库位于当前存储库之上的一个级别，并根据该业务逻辑命名。
或者您可以应用分层逻辑将此查询分配给您现有的某个存储库。
例如。 如果你有3张桌子（Driver - Car- DriveSessions），你需要显示用户的头名，车牌，车牌以及最后一个Drive会话的所有信息。
使用第一种方法，您将创建一个＆＃34; Summaries＆＃34;库。 或者你可以在＆＃34; Driver＆＃34;中添加它。存储库，因为所有这些实体都围绕着＆＃34; Driver＆＃34;。
我的观点是在EF中添加一个存储库是一种过度杀伤力。有些商业模式非常复杂，以至于无法抽象单个存储库中的所有内容。这就是为什么EF是为IQueryables设计的。将所有实体封装在具体的存储库后面，你将失去EF所提供的大部分糖果。
Opinions about using Repository pattern on top of EF
在我的应用程序中，我认为不是单个实体是非复杂的。使用具体的每个表存储库会降低性能并增加开发时间很多
答案 2 :(得分：0)
使用查询对象模式。这是一种更加坚固的方法。此外，分离查询和CRUD，创造了使用可能更适合自定义查询的不同，更合适的基础架构的机会。另请参阅：this
如果可以，请调查Vaughan Vernon所谓的“使用cas优化查询”，并注意他称之为“存储库掩码聚合错误设计”的气味。