代码之家  ›  专栏  ›  技术社区  ›  jlembke

域中定义的规范模式

  •  4
  • jlembke  · 技术社区  · 15 年前

    使用Linq to SQL和一个DDD风格的域层以及分离的存储库,是否有人对如何实现 specification pattern 不把L2S关注点注入域层,这还是可以理解的?:)

    我们有复杂的业务逻辑来选择一组事务数据,并且希望这些规则/规范归域所有。我们也做了很好的工作,让我们的领域坚持无知。

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

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

    4 回复  |  直到 15 年前
        1
  •  1
  •   Brett Veenstra    15 年前

    您是否考虑过将通用规范映射到 Expression 将转换为正确L2S语法的树?这似乎是你在这里碰到的主要问题。规范模式不是问题,但是 映射到L2S 是。

        2
  •  0
  •   slf    15 年前

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

        3
  •  0
  •   Mike Two    15 年前

    我最近也有同样的问题。不同的模式,但仍然依赖于SQL(L2S)。我试了两种不同的方法来避免渗漏。

    首先我们尝试使用DTO和映射层。所以我们编写了超级简单的对象,它们有一对一的表映射。它们都装饰有L2属性。然后我们编写了一个映射层来将dto映射到我们的业务对象。所有这些都是通过存储库模式从Doman驱动的设计中隐藏的。因此,业务对象的消费者根本不知道L2在幕后。

    接下来,主要是为了多样化。我们尝试使用L2S的XML映射特性,因此对象本身不需要属性。对于集合,我们公开了IEnumerable而不是任何L2S集合。如果您查看业务类的内部,您仍然可以检测到L2S(EntitySet或Ref)的一些用法。但这个阶层的消费者并不知道。所以有些泄漏,但没什么大不了的。

    最后我们坚持了第一种模式。第二个成功了,我们可以在不改变业务层接口的情况下替换L2,但我对XML映射并不满意。第一个模式在数据库和业务对象之间有一个更清晰的分离。需要更多的代码。第一个方法对我们来说也更有效,因为它允许我们以不同于表的方式来开发业务对象。在项目的早期,xml映射起作用,因为我们的对象几乎是一对一的表。

    最后我们在L2和磁畴之间加了一层。成功了。它需要更多的代码,但它是非常简单的东西。这一切都是可以测试的。

        4
  •  0
  •   Nathan Nathan    15 年前

    如果要避免从域层引用Linq2Sql,则必须处理表示实体的接口,而不是处理实际实体本身。然后需要在接口和实体之间建立一个映射层。

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

    推荐文章