mvc中的代码组织

我可能会创建一个类型CustomObjectRepository，它封装了表的连接，只返回CustomObjects。具体如何实现通用查找器函数取决于您使用的ORM类型（对于EF来说，这将是微不足道的，如果您进行手动映射，则会很复杂，但并非完全不可能）。

您可以有一个面向业务逻辑视图的存储库，它位于当前存储库的一个级别之上，并根据该业务逻辑命名。

或者，您可以应用分层逻辑将此查询分配给一个现有存储库。

例如。如果您有3个表（Driver-Car-DriveSessions），并且您需要显示用户的姓氏、汽车品牌、车牌和上次驾驶会话的所有信息。

使用第一种方法，您将创建一个"摘要"存储库。或者您可以将其添加到"驱动程序"存储库中，因为所有这些实体都是围绕"驱动程序（Driver）"定向的。

我的观点是，在EF之上添加一个Repository是一种过度的做法。有些业务模型非常复杂，不可能在单个存储库中抽象出所有内容。这就是为什么EF是为IQueryables设计的。将所有实体封装在具体的存储库中，您将失去EF所能提供的大部分糖果。

关于在EF 之上使用Repository模式的几点看法

在我的应用程序中，我认为没有一个实体是不复杂的。使用具体的每表存储库会降低性能并增加开发时间大量

使用查询对象模式。这是一个更加坚实的方法。此外，将查询和CRUD分离，为使用可能更适合自定义查询的不同、更合适的基础设施创造了机会。另请参阅：此

如果可以的话，调查Vaughan Vernon所说的"使用cas最优查询"，并注意他所说的"存储库掩盖聚合错误设计"的气味。