域中定义的规范模式

Question

使用Linq to SQL和具有解耦存储库的DDD样式域层，是否有人对如何实现specification pattern有任何好的想法，而不会将L2S问题泄露到域层中，这仍然是可以理解的？ ：）

我们在选择一组交易数据时有复杂的业务逻辑，并希望这些规则/规范归域所有。我们在保持域名持久性无知方面也做得很好。

这提出了一个问题，因为为了实现规范，域（据我所知）需要查看被查询的类型（L2S类型）。

有什么想法吗？

另外，由于我不想解释的原因，nHibernate是不可能的......：）

Answer 1

您是否考虑将通用规范映射到Expression树中，以便转换为正确的L2S语法？这似乎是你在这里遇到的主要问题。规范模式不是问题，但映射到L2S 是。

Answer 2

Linq-To-Sql类可以是部分的。这意味着您可以通过实现实现公共接口的partial来扩展它们。该接口可以在层之间共享，而不会出现您所描述的“流血”问题。其余的只是你的“IsStatisfiedBy”的细节，应该很容易封装。

Answer 3

我最近遇到了同样的问题。不同的模式，但仍然是LINQ to SQL（L2S）。我尝试了两种不同的方法来避免泄漏。

首先我们尝试使用DTO和映射层。因此，我们编写了超级简单的对象，这些对象具有与表的一对一映射。它们都装饰有L2S属性。然后，我们编写了一个映射层，将DTO映射到业务对象。所有这些都是通过Doman Driven Design的Repository模式隐藏的。因此，业务对象的消费者不知道L2S是否在幕后。

接下来，主要是为了变化。我们尝试使用L2S的XML映射功能，因此对象本身不需要任何属性。对于集合，我们暴露了IEnumerable而不是任何L2S集合。如果您查看业务类的内部，您仍然可以检测到L2S（EntitySet或Ref）的一些用法。但班上的消费者不知道。所以有些泄漏但没什么大不了的。

最后我们坚持第一个模式。第二个工作，我们可以替换L2S而不改变业务层的接口，但我对XML映射从未满意。第一种模式在数据库和业务对象之间有了更清晰的分离。花了更多的代码。第一个对我们来说也更好，因为它允许我们以不同于表格的方式发展业务对象。在项目的早期阶段，xml映射有效，因为我们的对象几乎是一对一的表。

所以最后我们在L2S和域之间放了一层。有效。它花了更多的代码，但它真的很简单。这一切都非常可测试。

Answer 4

如果要避免从域层引用Linq2Sql，则必须使用代表实体的接口，而不是使用实际实体本身。然后，您需要在接口和实体之间建立映射层。

我这样做了，发现这是一个严重的障碍。我切换到NHibernate用于新项目，对于较旧的项目，我只是不再担心直接引用Linq2Sql实体的域。在我看来，克服这种限制只是太多的时间成本。