我正在进行我的第一个.NET项目（.NET 3.5，ADO.NET和C#）。我们已经构建了实体模型，并尝试构建一个清晰的业务对象层。
我们有基本的实体模型，并希望在默认数据访问器（导航属性等）中添加某些业务级语义。
例如，假设我们在Person和BankAccounts之间有一对多关系。在业务层面上，我们想要添加冻结账户的功能。现在，我们希望能够从Person导航到：
- 所有他们的银行账户， - 他们未被冻结的银行账户，以及 - 他们被冻结的银行账户。
自然地，我们希望将名义案例作为默认值：如果我导航到Person.BankAccounts()，我希望它返回他们未被冻结的账户。我可以添加导航属性Person.FrozenBankAccounts()和Person.AllBankAccounts()。
我们提出的两种方法似乎都有相当多的代码气味。
我们有基本的实体模型，并希望在默认数据访问器（导航属性等）中添加某些业务级语义。
例如，假设我们在Person和BankAccounts之间有一对多关系。在业务层面上，我们想要添加冻结账户的功能。现在，我们希望能够从Person导航到：
- 所有他们的银行账户， - 他们未被冻结的银行账户，以及 - 他们被冻结的银行账户。
自然地，我们希望将名义案例作为默认值：如果我导航到Person.BankAccounts()，我希望它返回他们未被冻结的账户。我可以添加导航属性Person.FrozenBankAccounts()和Person.AllBankAccounts()。
我们提出的两种方法似乎都有相当多的代码气味。
- 我们找不到覆盖实体模型方法的方法。 因此，将
Person.BankAccounts()作为返回所有银行账户的访问器。 然后我们添加一个Person.FrozenBankAccounts()和一个Person.NonFrozenBankAccounts()。 - 向代码库添加另一个显式层，该层包装了对
BankAccounts的所有访问。
使用方法1的问题在于，名义上的业务案例（访问未冻结的银行账户）是其中最不直观的方法名称。
使用方法2时，当我们从实体模型层子类化对象时，必须重写每个方法以确保它不会返回底层层中的对象。因此，我们创建一个 BL_Person，它具有返回 BL_BankAccount 对象集合的 BankAccounts() 方法。但在这种情况下，所有那些代码似乎有点傻。
是否有比我们考虑过的两种方法更好的方法？ 如果没有更好的方法，我概述的这两种方法中哪一种似乎是更好的解决方案（考虑到我们需要处理50多个类）？
注意: 在进行网络搜索时，我发现了一封给微软的公开信，标题为ADO .NET Entity Framework Vote of No Confidence，似乎暗示着没有一个好的方法来实现清晰的关注点分离。