使用 Linq to SQL 和具有解耦存储库的 DDD 样式域层，是否有人对如何实现 specification pattern 而不会将 L2S 问题渗透到域层有任何好的想法，这仍然可以理解吗？ :)
我们有围绕一组交易数据选择的复杂业务逻辑，并希望这些规则/规范归域所有。我们在保持域持久性无知方面也做得很好。
这带来了一个问题，因为为了实现规范，域（据我所知）需要查看正在查询的类型（L2S 类型）。
有什么想法吗？
另外，由于我不想解释的原因，nHibernate 是不可能的.. :)
【问题讨论】：
标签： linq-to-sql domain-driven-design specification-pattern
您是否考虑过将您的通用规范映射到Expression 树中，该树将转换为正确的 L2S 语法？这似乎是您在这里遇到的主要问题。规范模式不是问题，但映射到 L2S 是问题。
【讨论】：
Linq-To-Sql 类可以是部分的。这意味着您可以通过实现实现通用接口的部分来扩展它们。该接口可以在层之间共享，而不会出现您描述的“出血”问题。剩下的只是你的“IsStatisfiedBy”的细节，应该很容易封装。
【讨论】：
我最近遇到了同样的问题。不同的模式，但仍然是 LINQ to SQL (L2S)。我尝试了两种不同的方法来避免泄漏。
首先我们尝试使用 DTO 和映射层。所以我们编写了超级简单的对象，这些对象与表具有一对一的映射关系。它们都装饰有 L2S 属性。然后，我们编写了一个映射层来将 DTO 映射到我们的业务对象。所有这些都通过 Doman Driven Design 的存储库模式隐藏起来。所以业务对象的消费者不知道 L2S 是在底层。
接下来，主要是为了多样化。我们尝试使用 L2S 的 XML 映射功能，因此对象本身不需要属性。对于集合，我们公开了 IEnumerable 而不是任何 L2S 集合。如果您查看业务类的内部结构，您仍然可以检测到 L2S（EntitySet 或 Ref）的一些用法。但是这个阶级的消费者不知道。所以有一些泄漏，但没什么大不了的。
最后我们坚持第一个模式。第二个可行，我们可以在不更改业务层接口的情况下替换 L2S，但我对 XML 映射从来不满意。第一个模式在数据库和业务对象之间有一个更清晰的分离。它需要更多的代码。第一个对我们也更有效，因为它允许我们以不同于表的方式发展业务对象。在项目的早期，xml 映射很有效，因为我们的对象与表几乎是一对一的。
所以最后我们在 L2S 和域之间放置了一层。有效。它需要更多的代码，但它真的很简单。这一切都非常可测试。
【讨论】：
如果您想避免从域层引用 Linq2Sql，则必须使用代表实体的接口，而不是使用实际实体本身。然后，您需要在接口和实体之间建立一个映射层。
我一直以这种方式工作，发现它是一个严重的障碍。我为新项目切换到 NHibernate，而对于旧项目，我不再担心域直接引用 Linq2Sql 实体。在我看来，克服这个限制实在是太耗费时间了。
【讨论】：