小编Bra*_*rek的帖子

该得墨忒耳定律指出你应该只给你关于直接了解对象说话.也就是说,不要执行方法链接与其他对象交谈.当您这样做时,您正在与中间对象建立不正确的链接,不恰当地将您的代码与其他代码耦合.

那很糟.

解决方案是针对您所知道的类,基本上公开简单的包装器,将责任委托给与其有关系的对象.

非常好.

但是,这似乎导致班级具有低凝聚力.它不再只是简单地对其所做的事情负责,但它也有代表在某种意义上,通过复制其相关对象的部分界面使代码更具凝聚力.

那很糟.

它真的会降低凝聚力吗？它是两个邪恶中的较小者吗？

这是发展的灰色区域之一,您可以在哪里讨论线路的位置,或者是否有强有力的,有原则的方式来决定在哪里划线,以及您可以使用哪些标准来做出决定？

我正在开发我的第一个.NET项目(.NET 3.5,ADO.NET和C#).我们已经构建了我们的实体模型,并且正在尝试构建一个干净的业务对象层.

我们已经获得了基本的实体模型,并且我们希望将某些业务级语义添加到默认数据访问器(导航属性等).

例如,让我们假设,我们之间有很多一对多的关系Person和BankAccounts.让我们假设在业务层我们想添加冻结帐户的功能.我们现在希望能够从Person导航到:

• 他们所有的银行账户,
• 他们的非冻结银行账户,和
• 他们冻结的银行账户.

当然,我们希望将名义案例作为默认情况:如果我导航,Person.BankAccounts()我希望它返回非冻结帐户.我可以添加导航属性Person.FrozenBankAccounts()和Person.AllBankAccounts().

我们提出的两种方法似乎都有相当多的代码味道.

1. 我们找不到覆盖实体模型方法的方法.因此,请将其Person.BankAccounts()作为返回所有银行帐户的访问者.然后我们添加一个Person.FrozenBankAccounts()和一个Person.NonFrozenBankAccounts().
2. 将另一个显式层添加到包装所有访问的代码库中BankAccounts.

方法1的问题在于,名义商业案例(访问未冻结的银行账户)是该批次最不直观的方法名称.

使用方法2,当我们从实体模型层继承对象时,我们必须覆盖每个方法以确保它不会从底层返回对象.所以我们创建一个BL_Person有一个BankAccounts()返回BL_BankAccount对象集合的方法.但在这种情况下,所有代码似乎都有些愚蠢.

有没有比我们考虑过的更好的方法？如果没有更好的方法,我所概述的两个中哪一个似乎是更好的解决方案(鉴于我们需要使用50多个课程)？

注意:在进行网络搜索时,我确实找到了一封给微软的公开信,题为" ADO .NET实体框架不信任投票"似乎意味着没有一种好方法可以明确区分关注点.