While this looks like an interesting project, I do have one or two reservations. First of all, there doesn’t appear to be any unit testing code. It would be good to see this included, as TDD is a pretty important practice these days.
Secondly, I have several serious reservations about the n-layered architecture in general and the Repository pattern in particular as it’s commonly implemented. My main concern is that the separation between the different layers is often not clear-cut, and attempting to segregate things out leads to concerns being mis-categorised, causing all sorts of problems such as poor testability, DRY violations, and performance problems. In particular, if you’re forcing everything to go to Entity Framework through a generic Repository wrapper, you’re not going to be able to specify prefetch paths for your queries, and that’s going to set you up for some serious select n+1
issues.
I’m also unhappy about the use of DTOs here. DTO stands for “Data Transfer Object” and as such DTOs are supposed to be for communication across the wire, often between machines on different servers. For these, your requirements are totally different from objects that can be passed around between layers in the same process. As such, you should only be using DTOs at a service boundary – they are really to WebAPI what views are to MVC. Using them to pass data from your application layer to your presentation layer is more often than not a waste of effort. Just let your entities go all the way to your views.
Separation of concerns is important, but it’s equally important to remember that it’s a means to an end and not an end in itself. It needs to solve a specific business problem, otherwise you’re just wasting your time and making a rod for your back. For what it’s worth, the way I prefer to approach separation of concerns is to have it driven by my unit tests – to have just enough of it to make my code testable and no more.