使用依赖注入的分层解决方案在 Visual Studio 项目中的何处放置接口
Where to place interfaces in a Visual Studio Project for a layered solution using Dependency Injection
我正在使用 WinForms、Visual Studio 2015、Entity Framework 6 和没有第 3 方容器的依赖项注入开发分层解决方案。目前，如果我将执行工作所需的接口放在一个共享项目中，我有一个结构允许 UI、BLL 和 DAL 不需要相互引用。请参见下图中的选项 A：
BLL 中的服务很薄，因为它们基本上调用 DAL 中的完整实现（即 BLL.GetDepts 调用 DAL.GetDepts。最初，我在 BLL 中定义了接口，如选项 B 所示. 选项 B 还要求 DAL 引用 BLL 以了解接口。此外，UI 还必须引用 BLL。但是，BLL 不需要引用 UI 或 DAL，因此它不依赖于任何一层。虽然选项 B 没有所有层依赖免费，但我开始怀疑这是否真的不是一个坏主意。使用选项 B，我仍然可以替换 UI 或 DAL，只要替换层满足接口要求，就不会影响 BLL。无论我使用选项 A 还是 B，对 UI 或 DAL 的任何更改仍需要使用 BLL 进行测试。所以我开始认为努力让所有层彼此独立并不是真正需要或实用的。
我开始质疑我转向选项 A 的原因是因为当我增加 类 接口的数量以扩展 BLL 功能时，我也在增加共享区域中的接口条目数量.目视查看我的 Visual Studio 项目，我认为任何需要 BLL 的东西的层都应该在 BLL 层中找到描述 BLL 需要什么的接口。 B选项就是这样做的。现在，对于选项 A，我是说任何希望实现 BLL 必须查看共享项目 BLL 接口部分的东西的层。现在一切正常，但我不确定走这条路是否会引起一些问题。
所以问题是，"Is there a problem with pursing option A as described above?"。
我会选择选项 B，因为它似乎是 MVC 模式的一个不错的实现。您可以在 here 阅读我写的几篇关于 MVC 模式的文章。 MVC 的优点是可读性。如果您以外的人可能正在维护代码，那么 MVC 将会很熟悉，或者至少很容易找到它们。
接口应该放在哪里首先取决于您引入接口的动机。
如果动机是为了获得松散耦合代码的好处，您最好遵守 SOLID principles. Specifically, according to the Dependency Inversion Principle, "clients [...] own the abstract interfaces" (APPP，第 11 章）。
这意味着接口应该在与使用接口的代码相同的库（assembly/Visual Studio 项目）中定义。
因此，您可以根据用途在各种不同的库中定义接口。您不需要将所有接口放在一个库中。
我正在使用 WinForms、Visual Studio 2015、Entity Framework 6 和没有第 3 方容器的依赖项注入开发分层解决方案。目前，如果我将执行工作所需的接口放在一个共享项目中，我有一个结构允许 UI、BLL 和 DAL 不需要相互引用。请参见下图中的选项 A：
BLL 中的服务很薄，因为它们基本上调用 DAL 中的完整实现（即 BLL.GetDepts 调用 DAL.GetDepts。最初，我在 BLL 中定义了接口，如选项 B 所示. 选项 B 还要求 DAL 引用 BLL 以了解接口。此外，UI 还必须引用 BLL。但是，BLL 不需要引用 UI 或 DAL，因此它不依赖于任何一层。虽然选项 B 没有所有层依赖免费，但我开始怀疑这是否真的不是一个坏主意。使用选项 B，我仍然可以替换 UI 或 DAL，只要替换层满足接口要求，就不会影响 BLL。无论我使用选项 A 还是 B，对 UI 或 DAL 的任何更改仍需要使用 BLL 进行测试。所以我开始认为努力让所有层彼此独立并不是真正需要或实用的。
我开始质疑我转向选项 A 的原因是因为当我增加 类 接口的数量以扩展 BLL 功能时，我也在增加共享区域中的接口条目数量.目视查看我的 Visual Studio 项目，我认为任何需要 BLL 的东西的层都应该在 BLL 层中找到描述 BLL 需要什么的接口。 B选项就是这样做的。现在，对于选项 A，我是说任何希望实现 BLL 必须查看共享项目 BLL 接口部分的东西的层。现在一切正常，但我不确定走这条路是否会引起一些问题。
所以问题是，"Is there a problem with pursing option A as described above?"。
我会选择选项 B，因为它似乎是 MVC 模式的一个不错的实现。您可以在 here 阅读我写的几篇关于 MVC 模式的文章。 MVC 的优点是可读性。如果您以外的人可能正在维护代码，那么 MVC 将会很熟悉，或者至少很容易找到它们。
接口应该放在哪里首先取决于您引入接口的动机。
如果动机是为了获得松散耦合代码的好处，您最好遵守 SOLID principles. Specifically, according to the Dependency Inversion Principle, "clients [...] own the abstract interfaces" (APPP，第 11 章）。
这意味着接口应该在与使用接口的代码相同的库（assembly/Visual Studio 项目）中定义。
因此，您可以根据用途在各种不同的库中定义接口。您不需要将所有接口放在一个库中。