Loose project coupling causes problems in .NET Core solution

Question

we started a new project in which back end consists of several layers (each in different project).

For simplifaction I'll define a few:

1. Project.Data -data layer with access to db
2. Project.Repository - repos
3. Project.Repository.Interfaces - only repos interfaces
4. Project.WebApi - API

Our team leader proposed we should block access to resources between the projects on the reference level. Now the only thing API will be referencing in this examnple is Project.Repository.Interfaces. There we inject interfaces using Dependency Injection. Like I said this is a simple version not including Services and Dtos.

Idea behind this was that WebAPI should only use DI to access resources. Also WebAPI should have access to DTO's not directly to database entities. This is all great but of course there are a few problems that were encountered and I'm not sure how to solve them:

a) Nuget packages installed into Project.Repository is not being copied to WebAPI (Runtime exception about missing dll)

b) using .NET Core CLI and dotnet watch run to start a project locally doesn't track changes in the child projects since they are not directly referenced.

I see the vision behind this loose coupling idea but this is really cumbersome. Is this a tradeoff you have to live with in such a situation or is there a solution for this ?

Regards

Answer 1

Yes it's a hassle to not build whatever you need, where you need it, the moment you realize you need it. Procedural code is much easier to write. Always has been. Always will be. Thing is a mature developer's number one concern isn't writing speed. It's reading speed.

Making your dependencies explicit helps me read your code. Do that and I can use your code when it's time to make changes. I'd rather not have to burn it to the ground. Thinking about the next poor code monkey that will have to deal with my code is how I get over it.

You mention that working this way breaks some of your tools. This is true. My biggest peeve is clicking on something and getting the abstraction not the implementation. All I can say to that is we need better tools.

The cost of working dynamically is static analysis. The cost of working statically is living with static code. Pick your poison.

Answer 2

Your problem is that you are missing an Entry point in your architecture.

You can make all project loose coupled and probably should, but you always will need one project which will glue all others together and run application.

For application it is usually a project with Main method.
The way how ASP.NET Core works your entry point project should be a WebAPI project.

So trying to get rid of other dependencies in WebAPI isn't correct approach as you noticed already.