Where to place interfaces in a Visual Studio Project for a layered solution using Dependency Injection
I am developing a layered solution using WinForms, Visual Studio 2015, Entity Framework 6, and dependency injection without a 3rd party container. At the present time, I have a structure which allows the UI, BLL, and DAL to not need to reference each other if I place the interfaces necessary to carry out work in a shared project. See option A in diagram below:
The services in BLL are thin as they basically call the full implementations in the DAL (i.e. BLL.GetDepts calls DAL.GetDepts. Originally, I had the interfaces defined in the BLL as shown in option B. Option B also required the DAL to have a reference the BLL to understand the interfaces. Additionally, the UI also had to have a reference to the BLL. The BLL, however, did not need to reference the UI or DAL so it had no dependency on either layer. Although option B did not have all layers dependent free, I am beginning to wonder if it was actually not a bad idea. With option B, I can still replace the UI or DAL without affecting the BLL as long as the replacement layers honor the interface requirements. Whether I use option A or B, any changes to the UI or DAL will still require testing with the BLL. So I'm beginning to think striving to have all layers independent of each other was not really needed or pragmatic.
The reason I have begun to question my move to option A is because as I increase the number of classes with interfaces to expand BLL functionality, I am also increasing the number of interface entries in the shared area. Visually looking at my Visual Studio project I am thinking any layer which needs something from the BLL should find the interface describing what the BLL needs in the BLL layer. This is what option B did. Now, with option A, I am saying any layer wishing to implement something the BLL must look to the shared project BLL interfaces section. It all works for now but I'm not sure if pursuing this path is going to cause some problem.
So the question is, "Is there a problem with pursing option A as described above?".
Where interfaces should go depends on your motivation for introducing interfaces in the first place.
If the motivation is to harvest the benefits of loosely coupled code, you'd be best off adhering to the SOLID principles. Specifically, according to the Dependency Inversion Principle, "clients [...] own the abstract interfaces" (APPP, chapter 11).
This means that an interface should be defined in the same library (assembly/Visual Studio project) as the code that uses the interface.
Thus, you can have interfaces defined in various different libraries, depending on use. You don't need to put all interfaces in a single library.