我正在开发我的第一个 .NET 项目(.NET 3.5、ADO.NET 和 C#)。我们已经构建了我们的实体模型,并正在尝试构建一个干净的业务对象层。
我们已经有了基本的实体模型,并且我们希望将某些业务级语义添加到默认数据访问器(导航属性等)。
例如,假设我们在 Person
之间存在多对多关系。和 BankAccounts
.假设我们想在业务层添加卡住帐户的功能。我们现在希望能够从 Person 导航到:
自然,我们希望将名义情况设为默认值:如果我导航
Person.BankAccounts()
我希望它退回他们未卡住的帐户。我可以添加导航属性 Person.FrozenBankAccounts()
和 Person.AllBankAccounts()
.我们提出的两种方法似乎都有相当多的代码气味。
Person.BankAccounts()
作为返回所有银行账户的访问者。然后我们添加一个 Person.FrozenBankAccounts()
和 Person.NonFrozenBankAccounts()
. BankAccounts
的所有访问。 . 对于方法 1,问题在于名义业务案例(访问未卡住的银行账户)是该批处理中最不直观的方法名称。
使用方法 2,当我们从实体模型层子类化对象时,我们必须重写每个方法以确保它不会从底层返回对象。所以我们创建一个
BL_Person
其中有一个 BankAccounts()
返回 BL_BankAccount
集合的方法对象。但在这种情况下,所有这些代码似乎有点傻。有没有比我们考虑的两个更好的方法?如果没有更好的方法,我概述的两种方法中的哪一种似乎是更好的解决方案(鉴于我们需要使用 50 多个类)?
注:在进行网络搜索时,我确实找到了一封致微软的公开信,标题为 ADO .NET Entity Framework Vote of No Confidence。这似乎意味着没有一种很好的方法来明确分离关注点。
最佳答案
我没有使用 LINQ to Entities 的经验,但您的问题敲响了警钟。在我的上一个项目中,我在使用另一个 ORM 时遇到了几乎相同的问题。我没有让业务对象层的客户端直接使用 ORM 生成的类或复制所有类并实现大量转发功能,而是定义了接口(interface)。您的业务对象层的客户端只能看到这些接口(interface),而您的实体类将实现这些接口(interface),具有以下优点:
关于.net - 向 ADO .NET Entity Framework 添加业务层,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/433022/