I'm trying to create a MVC application in net core 2.1 using the eshoponweb example application. Ive read that in entity Framework core there's no great benefit of putting a repository layer in and to just use the ef dbcontext directly. How would I do this in a clean architecture scenerio. In the example application the dB context is in the infrastructure layer and the business services logic is all in the application core. I thought about moving either of these but then won't that prevent the separation that clean architecture is looking to achieve. https://github.com/dotnet-architecture/eShopOnWeb and https://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework-core/
1 Answers
I think where a lot of developers get hung up is in thinking that you need your own layers. In onion architecture, you'll generally have a "data" layer, typically referred to as DAL. When you're using an ORM like EF, that is your data layer. In other words, rather than having a separate class library you create to work with the database, EF is that library, and therefore, you'd use it just like you'd use your own DAL library, if you had one.
Try not to get so hung up on layers and "clean" architecture. In truth, the cleanest architecture is a single project. It's only when things start to get unwieldy with that, that it makes sense to break out "layers". In other words, build the simplest unit of functionality you can. If there's a bunch of code involved, you find yourself repeating code, you have too many dependencies, etc. then start to break stuff out as part of the refactoring process. Eventually, you may end up with all the fancy layers and 100 different class libraries, or whatever, but it's folly to try to start there. If your app doesn't actually need something, it's stupid to add it. Plain and simple.
For what it's worth, this is probably one of the most unsung benefits of TDD, or test driven development. You write a test to ensure that one particular thing happens that you want, then you write the code to satisfy that test. Importantly, you only write the code to satisfy that test. That means naturally, you start simple and move to complexity. The refactor cycle of the old red-green-refactor TDD approach is where you clean up the code, abstracting things where necessary, moving logic out into reusable libraries and such. Even if you don't do the whole test-first approach to coding, it's still highly beneficial to look at development this way. You know what you need to build, so build the most simplistic thing that technically satisfies that requirement. Then refactor. Build the next requirement, and refactor again. Let you application naturally grow into what it actually needs to be, rather than trying to assert some sort of architecture, pattern, or process on it from the get-go.
Related