如何修复此循环依赖？

Question

我在Gary McLean Hall的 Adaptive Code via C＃的单元测试/测试驱动开发部分。我的问题是基于书中可能包含错误的示例。以下是3层架构中示例splice的UML图：

我的解决方案分为四个与图层对应的不同项目：User_Interface，Business_Logic，Data_Access和Unit_Tests。

我的问题与AccountService界面有关。在本书中，作者为伪类（在Unit_Tests项目中）编写了以下代码，用于模拟用于单元测试的IAccountRepository接口的实现：

IAccountRepository

我遇到的问题是class FakeAccountRepository : IAccountRepository { private Account account; public FakeAccountRepository(Account account) { this.account = account; } public Account GetByName(string accountName) { return account; } } 方法返回GetByName()类型。如果我尝试将Account中的签名更改为IAccountRepository返回类型，则无法找到该类型。由于Account类是业务逻辑层的一部分，如果我尝试添加对Business_Logic项目的引用（来自Data_Access项目），Visual Studio会给我一个“循环依赖”错误。

这是有道理的，因为数据访问层是底层，不应该依赖于它自身之上的任何层......但是没有引用我在Account接口中不能有Account返回类型。

作者是否忘记了什么？我应该创建IAccountRepository界面，更改IAccount方法以返回GetByName()类型，并让IAccount实现Account界面吗？如果没有，我该如何解决这个问题？

Answer 1

我在这里看到两种可能性：

1. 添加名为“Common”的项目或类似的东西 - 在那里存储Account类，并在数据访问和业务中添加对Common的引用逻辑项目
2. 为帐户创建两个类：一个在数据访问中，一个在业务逻辑中。两者都具有相同的字段（属性）。第二个类应该是AccountModel的名称。 这是我在专业解决方案中看到的方法。基本上，数据访问层具有实体类，而业务逻辑层具有模型类。当服务从存储库中提取数据时，它会将Account类型的对象映射到AccountModel类型的对象

Answer 2

作者很可能将此作为单个可执行文件编写，并将所有内容都放在一个项目中，以便数据访问层可以看到帐户类。

您可以自己完成此操作，只需将“图层”分隔到不同的名称空间即可提供逻辑分离。

Answer 3

我最终采取了与此处答案不同的方法。我在数据访问层中创建了一个名为IAccount的接口，并使用IAccount作为GetByName()方法的返回类型。这解决了我的问题，仍然保持了分层架构。