域中定义的规范模式

Question

使用Linq to SQL和具有解耦存储库的DDD样式域层，对于如何实现specification pattern而不将L2S问题渗透到域层，大家有什么好主意吗?这仍然是可以理解的:)

我们有复杂的业务逻辑围绕着一组事务数据的选择，并且希望这些规则/规范归Domain所有。我们还做了很好的工作来保持我们的域持久化是不知情的。

这带来了一个问题，因为为了实现规范，域(据我所知)需要看到被查询的类型(L2S类型)。

有什么想法吗？

此外，由于我不想解释的原因，nHibernate是不可能的。:)

Answer 1

您是否考虑过将通用规范映射到可以转换为正确L2S语法的Expression树中？这似乎是您在这里遇到的主要问题。规范模式不是问题所在，但是映射到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和域之间加了一层。啊，真灵。它需要更多的代码，但这是非常简单的东西。这一切都是非常容易测试的。