.net - 向 ADO .NET Entity Framework 添加业务层

Question

我正在开发我的第一个 .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。这似乎意味着没有一种很好的方法来明确分离关注点。

Answer 1

我没有使用 LINQ to Entities 的经验，但您的问题敲响了警钟。在我的上一个项目中，我在使用另一个 ORM 时遇到了几乎相同的问题。我没有让业务对象层的客户端直接使用 ORM 生成的类或复制所有类并实现大量转发功能，而是定义了接口(interface)。您的业​​务对象层的客户端只能看到这些接口(interface)，而您的实体类将实现这些接口(interface)，具有以下优点:

在直接的情况下(没有业务逻辑)，接口(interface)的开发开销是最小的。对于大多数成员，您不需要实现转发功能，只需从接口(interface)“派生”实体类并完成它

在您提到的情况下，您可以在接口(interface)中拥有一个属性 BankAccounts 并通过显式接口(interface)实现让它转发到实现实体的 NonFrozenBankAccounts 。您当然也可以添加任何类型的检查

作为一个额外的好处，您可以轻松地交换底层持久层，而无需明显更改客户端代码