1

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

Improve this question
10
  • Do you have any control over the consumers of your Web API?
    – Graham
    Dec 13, 2018 at 15:08
  • @Graham I don't see how thats connected but yes.
    – cah1r
    Dec 13, 2018 at 15:20
  • 1
    can you explain exactly how the projects are joined? are you loading the dlls at runtime time via reflection?
    – Ewan
    Dec 13, 2018 at 15:48
  • We have defined pre-build and post-build events in .csproj. For example: copy $(ProjectDir)..\Proj.Repository\bin\$(ConfigurationName)\netcoreapp2.1\Proj.Core.Repository.dll $(OutDir)
    – cah1r
    Dec 13, 2018 at 16:20
  • @MateuszMigała: if you have such pre- and postbuild events, should that not prevent the missing DLL problem you mentioned? And if it should, but sometimes failed, find the root cause and work on that.
    – Doc Brown
    Dec 13, 2018 at 16:38

2 Answers 2

Reset to default
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.

Improve this answer
2
  • I like the idea but it causes issues were during DEV test I catch myself using the ,,old" version of some dll. Or the issue with missing references I mentioned in the post. The main advantage is that I enforce proper project architecture but that could be mitigated by code review. The main disadvantage are hard to catch runtime errors and more time spend during development.
    – cah1r
    Dec 13, 2018 at 15:18
  • 4
    The cost of working dynamically is static analysis. The cost of working statically is living with static code. Pick your poison.
    – candied_orange
    Dec 13, 2018 at 15:30
0

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.

Improve this answer
3
  • Well actually WebApi glues everything together but the loose coupling approach on project level is causing some headaches and may lead to other kinds of mistakes that will occur in runtime. This could maybe be mitigated by code review.
    – cah1r
    Dec 14, 2018 at 12:42
  • What you mean by loose coupling approach on project level. WebAPI project will have references to all projects in solution. Repository project will have reference to Repository.Interfaces because it implements it. And possibly all projects have reference to Dto project.
    – Fabio
    Dec 14, 2018 at 19:39
  • WebApi has reference only to Project.Service.Interfaces and Project.Dtos. Other dlls are not referenced and copied using Build actions.
    – cah1r
    Dec 17, 2018 at 9:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.