architecture – Repository Pattern with Services Layer – Good Practice?

This is my first time I am using repository pattern and applying a layered architecture in a project. I have followed the article found here. The complete code found on the article can also be found on the writer’s github.

I read the whole article beginning to end before getting my hands on the keyboard to start coding. It al made sense (still does).

I am not sure if I have to summarise the whole article here but in simple terms, he divided his solution into 4 projects. Core, Data, Services and WebApi. Repository Pattern and UnitOfWork is used to abstract data access.

After reading the article I decided to apply the very same logic to my project. After doing so, I realised it took me the whole day and I found myself writing a lot and a lot of code which seemed unnecessary and duplicated. For example, in this article he only have two entities. Hence it seemed like a very simple application. I currently have 28 and that’s only the beginning! This ment, apart from my actual model, I ended up having 28 separate repository interfaces, 28 separate service interfaces, 28 actual repositories, 28 actual service classes and similar number of DTOs (Resource classes) for mapping purposes.

So. I am happy to do the extra work if it will prove to be a solid foundation for my project and if it will contribute positively to my learning progress. However, something inside tells me I’ve done a lot of unnecessary work, which either could be simplified or probably have a better way of doing. Hence, I am here seeking advice if this article is guiding me in the right direction.

I am using the latest versions (including pre-release) of DotNet Core and Entity Framework Core.