![]() |
1
1
您是否考虑过将通用规范映射到
|
![]() |
2
0
Linq到Sql类可以是部分的。这意味着您可以通过实现实现公共接口的部分来扩展它们。该接口可以在层之间共享,而不会出现您所描述的“出血”问题。剩下的只是“IsStatisfiedBy”的细节,应该很容易封装。 |
![]() |
3
0
我最近也有同样的问题。不同的模式,但仍然依赖于SQL(L2S)。我试了两种不同的方法来避免渗漏。 首先我们尝试使用DTO和映射层。所以我们编写了超级简单的对象,它们有一对一的表映射。它们都装饰有L2属性。然后我们编写了一个映射层来将dto映射到我们的业务对象。所有这些都是通过存储库模式从Doman驱动的设计中隐藏的。因此,业务对象的消费者根本不知道L2在幕后。 接下来,主要是为了多样化。我们尝试使用L2S的XML映射特性,因此对象本身不需要属性。对于集合,我们公开了IEnumerable而不是任何L2S集合。如果您查看业务类的内部,您仍然可以检测到L2S(EntitySet或Ref)的一些用法。但这个阶层的消费者并不知道。所以有些泄漏,但没什么大不了的。 最后我们坚持了第一种模式。第二个成功了,我们可以在不改变业务层接口的情况下替换L2,但我对XML映射并不满意。第一个模式在数据库和业务对象之间有一个更清晰的分离。需要更多的代码。第一个方法对我们来说也更有效,因为它允许我们以不同于表的方式来开发业务对象。在项目的早期,xml映射起作用,因为我们的对象几乎是一对一的表。 最后我们在L2和磁畴之间加了一层。成功了。它需要更多的代码,但它是非常简单的东西。这一切都是可以测试的。 |
![]() |
4
0
如果要避免从域层引用Linq2Sql,则必须处理表示实体的接口,而不是处理实际实体本身。然后需要在接口和实体之间建立一个映射层。 我一直这样工作,发现这是一个严重的障碍。我切换到NHibernate用于新项目,而对于旧项目,我只是不再担心直接引用Linq2Sql实体的域。在我看来,克服这种限制实在是太费时了。 |