使用依赖注入

Question

我正在使用WinForms，Visual Studio 2015，Entity Framework 6和没有第三方容器的依赖注入开发分层解决方案。目前，我有一个结构，如果我放置在共享项目中执行工作所需的接口，则允许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接口部分的内容的层。这一切现在都有效，但我不确定追求这条道路会不会引起一些问题。

所以问题是，“如上所述追求选项A是否存在问题？”。

Answer 1

接口的位置取决于您首先引入接口的动机。

如果动机是为了获得松散耦合代码的好处，那么你最好坚持使用SOLID principles。具体来说，根据Dependency Inversion Principle，“客户[...]拥有抽象接口”（APPP，第11章）。

这意味着应该在与使用接口的代码相同的库（assembly / Visual Studio项目）中定义接口。

因此，您可以根据用途在各种不同的库中定义接口。您不需要将所有接口放在单个库中。

Answer 2

我会使用选项B，因为它似乎是MVC模式的一个不错的实现。您可以在here阅读我撰写的有关MVC模式的几篇文章。 MVC的优点是可读性。如果除了你自己以外的其他人可能正在维护代码，那么MVC将会很熟悉，或者至少很容易查找它们。