eShopOnWeb Architecture (12/16) - uses the repository and specification pattern
eShopOnWeb uses the repository pattern over Entity Framework (I'm not getting into this debate again ??). When we use this pattern we can sometimes see a proliferation of similar methods such as GetBasketByBuyerId, GetBasketByBasketId etc.
eShopOnWeb uses the specification pattern to encapsulate queries and their details. This means we don't have a proliferation of repository methods but rather just a few (eg. GetBySpecAsync) which take a 'specification' as input. The queries however have really just been moved to another location and we'll likely still have a similar amount of specifications as repository methods.
For example... below we can see that instead of having two repository methods with a query each for GetBasketByBasketId and GetBasketByBuyerId scenario eShopOnWeb has a BasketWithItemsSpecification class which has two queries via two different constructors.
What does everyone think? … for me this is kind of like taking an abstraction (the repository pattern) and?then splitting it in two. It’s makes the architecture harder to navigate and understand for little if any benefit.
Follow for daily .NET posts | Microsoft MVP | Senior Software Engineer
3 年Part 1 - uses marker interfaces to communicate intent and enforce design constraints https://lnkd.in/d-PWGS3J Part 2 - uses Value Objects to model domain concepts without identity https://lnkd.in/dX_eFuti Part 3 - uses custom exceptions to more explicitly express what has gone wrong https://lnkd.in/dHpp2-E3 Part 4 - uses the MediatR library to keep controllers thin https://lnkd.in/dX7VfD6i Part 5 - makes regular use of Guard Clauses https://lnkd.in/d--hmXz5 Part 6 - uses private setters and non default constructors to support encapsulation which helps keep the model valid https://lnkd.in/dEwY_iep Part 7 - encapsulates navigation collections so consumers can’t edit them directly https://lnkd.in/dk5DXRKh Part 8 - uses in memory caching to avoid sending unnecessary queries to the DB https://lnkd.in/dg_Y5qUx Part 9 - uses the Aggregate root pattern to ensure child objects are not manipulated out of context https://lnkd.in/d46XBjeC Part 10 - has unit tests which test very low level implementation details https://lnkd.in/dd69BEpU Part 11 - uses AutoMapper https://lnkd.in/deeCwcBa Part 12 - uses the repository and specification pattern https://lnkd.in/dd6RiDUy Part 13 - has some single implementation interfaces https://lnkd.in/drkhgk8T Part 14 - uses parameterized tests https://lnkd.in/dgqTTP4F Part 15 - has a really nice example of the Interface Segregation Principle https://lnkd.in/dgkn5fqx Part 16 - uses clean architecture https://lnkd.in/d-bS24cY
Do you need help with a software project? I can ensure that your applications are secure, fast, flexible and loved by your users
3 年Seems like you'd have to find a way around issues like duplicate constructors where you have two int based "Gets" as well. The example gets around this because basketId and buyerId are different types but how would it work if both were ints?
Software Engineer
3 年I think this would be my least favorite way to do it. What I’m doing now is somewhere between GetBy and a CQRS. My services (one layer above the repos) has the GetBy method that accepts an object with parameters. This object is the same dto that the client would see in swagger so they can easily decide how they want or should query. However, the pattern quickly falls apart on complex queries or queries across domains using the same API. I’m wondering who out there successfully uses OData.
Practical .NET and Software Architecture Tips | Microsoft MVP
3 年I have used both approaches before. And I don't particularly dislike either one. They both have their pros and cons, and I think you should try them out for yourself before deciding what's right for you ??♂?