mvc中的代码组织

在我们的Web应用程序中，我们拥有带CRUD操作和通用查找程序功能的存储库，例如userRepository.Get(u => u.Username == someString)。和UserRepository将只返回User对象。mvc中的代码组织

但如果我有一个复杂的查询其做加盟之间Table1，Table2和Table3并返回CustomObject包含这3代表的某些属性。

我应该把这些查询放在服务层吗？存储库是否只包含基本的CRUD和查找程序功能，并返回基本的实体对象而没有其他内容？我问，因为有人告诉我，没有查询应该在服务层...

来源

2015-12-22 Aleksa

这是您需要查看Domain驱动设计的地方，您可以使用存储库执行此操作，但在应用程序复杂时它不是通用的 – brykneval

您也可以查看此文章：http：//programmers.stackexchange。com/questions/218011/how-accurate-is-business-logic-should-in-a-service-not-in-a-model – Peter

我可能会创建一个类型CustomObjectRepository它封装表的加入和返回只有CustomObject s。具体如何实现通用查找器函数取决于您使用的是哪种类型的ORM（对于EF来说这很简单，复杂但如果执行手动映射则根本不可能）。

来源

2015-12-22 09:28:45

您可以拥有一个业务逻辑视图导向仓库，它根据该业务逻辑在当前仓库的顶部和顶部放置一个级别。

或者您可能会将分配此查询的分层逻辑应用到您现有的某个存储库。

例如。如果您有3张桌子（Driver - Car- DriveSessions），并且您需要显示用户的名字，车牌，车牌和上次Drive会话的所有信息。

使用第一种方法，您将创建一个“Summaries”存储库。或者你可以在“Driver”存储库中添加它，因为所有这些实体都是以“Driver”为导向的。

我的意见是在EF的顶部添加一个仓库是一个矫枉过正。有些商业模式非常复杂，以至于无法在单个存储库中提取所有内容。这就是EF为IQueryable设计的原因。将所有实体封装在具体存储库后面，您将失去大部分糖果EF所提供的功能。

Opinions about using Repository pattern on top of EF

在我的应用我认为不是一个单一的实体非复杂。使用具体的每个表存储库会降低性能并增加开发时间A LOT

来源

2015-12-22 10:33:05

还有其他一些方法可以在EF之上编写存储库， IQueryables，但仍提供ORM特定代码的包装层 - 例如http://blogs.msdn.com/b/mrtechnocal/archive/2014/03/16/asynchronous-repositories.aspx（当然，有仍然是客户端代码和EF之间的耦合，因为对EF不支持的IQueryables的操作会抛出异常，但分离比直接使用EF好得多）。 –

是的我使用了一种有点类似的方法，但我认为我不会称之为经典的“存储库模式”。它主要是围绕着我认为的实体框架的包装。 –

使用查询对象模式。这是一个更坚实的方法。此外，分离查询和CRUD，为使用更适合定制查询的不同更合适的基础架构创造了机会。另请参阅：this

如果可以，请调查Vaughan Vernon所称的“使用cas优化查询”，并提防他称之为“存储库掩码聚合错误设计”的气味。

来源

2015-12-23 15:31:07

mvc中的代码组织

回答

相关问题