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