首先，对我下面的脑部空间的长描述道歉。我仍然围绕着许多这些新想法，所以我确定我正在描述错误的东西。如果我错了，请随时纠正我。
我们处于新的ASP.net MVC2站点的R＆amp; D阶段，并希望确保我们可以1）将我们的数据存储与应用程序分离，2）允许我们的应用程序通过单元测试进行测试3 ）允许我们更改我们的数据存储区或使用除Linq2SQL以外的其他东西。
这个看似简单的目标为我开辟了一个全新的世界，其中包括Repository模式，IoC，DI以及其他各种让我畅游的东西。以下是迄今为止关注的内容，或者至少我认为是实现目标的一个有点正确的计划：
我们将有许多 ISpecificRepository 接口，用于定义接口用户与基础数据存储之间的合同。
SpecificRepository 实现将查询特定数据存储并返回表示我们的域对象（或其集合）的POCO。
我们的服务层将使用传递给各种服务方法的ISpecificRepository实例执行特定于应用程序的业务逻辑，并将这些POCO域对象传递回我们的表示层。
如上所述，我们计划使用Linq2SQL为应用程序实现我们的特定存储库，并决定通过为我们的域对象创建POCO来分离我们的服务层与此实现，并创建到这些对象的映射到这些对象的映射。 LINQ生成的实体。然后，在服务层中，我们可以创建业务逻辑来查询存储库，添加数据，以及为每个用例执行我们需要执行的任何其他操作。这似乎很好，但我担心的是，由于我们使用的是Linq2SQL，我们特定的Linq存储库实现现在必须包含服务层有效实现业务逻辑所需的所有 Get 查询。
我很好奇这是否会以某种方式打破存储库模式，因为我们现在只在服务层而不是存储库中容纳特定于应用程序的逻辑。
我认为我们需要这样做的原因是我可以使用各种DataLoadOptions等在我的特定Linq存储库上编写更高效的Linq查询，而无需将IQueryable从我的存储库返回到我的服务层，在那里它似乎那种逻辑实际上属于。此外，我看到的所有示例IRepository接口看起来都非常轻量级，并且只为GetByID，GetAll，Find，Insert，Delete和SubmitChanges提供了一些方法到底层数据存储。就我而言，听起来我的特定存储库将会做更多的事情。
感谢您阅读此内容。任何能够澄清我的误解的帮助都将不胜感激。
-Mustafa
答案 0 :(得分：2)
我们特定的Linq存储库 实施现在必须要住 所有的Get查询都是 服务层需要实现 有效的业务逻辑。
我很好奇这是否是某种方式 打破存储库模式
完全没有。存储库是域实体的集合。如果我有Repository Accounts，那么想要Accounts.ThatAreOverdue()是完全合理的。
我个人更喜欢流利的命名。 Accounts.ThatAreOverdue()感觉好于AccountRepository.GetOverdue() ..但我想这是一个偏好点。
此外，所有示例IRepository 我见过的界面看起来很棒 轻巧，只提供一些 GetByID，GetAll，Find的方法， Insert，Delete和SubmitChanges to 基础数据存储。
Repository接口可以很薄。 Find旨在与规范模式一起使用。将条件封装在另一个对象中。标准的实现可以传递Linq2Sql对象从中进行查询 - 但是对于内存域对象重用标准类将更加困难（与涉及Linq2Sql的数据库相比）。
我们的服务层将执行 应用特定的业务逻辑 使用的实例 ISpecificRepository传递给了 各种服务方法并传递这些 POCO域对象回到我们的 表示层。
您是说您的逻辑将全部在服务中，而“域对象”将是视图中绑定的属性包？
我认为我不推荐这样做。
如果在视图中也使用了应用程序逻辑中使用的相同对象，那么您已将两个应用程序层紧密耦合，并且经验说明会导致问题。如果View使用相同的对象，则通过更改在服务和域中保持一致性将非常困难。视图将需要数据，并且它们将不可避免地陷入他们并不真正属于域的位置。