Repositories with EF/EFCore

Solarion

Solarion

Honorary Master
Joined
Nov 14, 2012
Messages
28,059
Reaction score
17,815
I don't think we need repositories do we? I've heard EF has it's own UnitOfWork so I'm guessing no need for that either. It seems like almost anything added onto EF to handle data is just more abstraction.

I don't like the idea of coupling my UI or even my Service layer straight onto the context so what then is the alternative? Is it possible to Inject the context into a service layer?

An interesting take on building a clean repository.

 
Last edited:
Definitely don't need repositories that wrap DbContext.


I have completely abandoned DDD architecture (controller, service, repository, db) in favour of pseudo clean architecture with vertical slice architecture with MediatR.
 
Dont really need EF for modern development. I`m not sure how a Repo pattern fits in with Service Orientation.
 
_kabal_ said:
What does this mean?
Click to expand...
It means that using EF in a micro-service seems like a bad idea. A micro-service needs to be loosely coupled in terms of functionality and also be lightweight in order to scale efficiently. The concept of a centralized local memory is not applicable to micro-services, there is no "central application". The micro-services I have built all use the old .NET SQL Client, can`t have an ORM in a micro-service. There might be a case to use EF in micro-services, but I have not yet encountered this case.
 
Yeah what I`m saying is that the monolithic app has officially died. Cloud native micro-services is whats hot now.
 
_kabal_ said:
Definitely don't need repositories that wrap DbContext.


I have completely abandoned DDD architecture (controller, service, repository, db) in favour of pseudo clean architecture with vertical slice architecture with MediatR.
Click to expand...

Very interesting! I found this which I'm going to have a poke around with. I'm struggling to get his Infrastructure Layer loaded when opening but otherwise it seems to be a fairly tight app.

68747470733a2f2f692e6962622e636f2f447a51625970632f7673612e706e67


github.com

GitHub - sandeepgangwar/Vertical-Slice-Architecture: ASP.Net Core 2.2 Restful WebAPI starter template created with vertical slices

ASP.Net Core 2.2 Restful WebAPI starter template created with vertical slices - sandeepgangwar/Vertical-Slice-Architecture
github.com github.com
 
Benedict A55h0le said:
It means that using EF in a micro-service seems like a bad idea. A micro-service needs to be loosely coupled in terms of functionality and also be lightweight in order to scale efficiently. The concept of a centralized local memory is not applicable to micro-services, there is no "central application". The micro-services I have built all use the old .NET SQL Client, can`t have an ORM in a micro-service. There might be a case to use EF in micro-services, but I have not yet encountered this case.
Click to expand...

A microservice can have its own database, in fact, that is pretty typical.
 
Benedict A55h0le said:
Yeah what I`m saying is that the monolithic app has officially died. Cloud native micro-services is whats hot now.
Click to expand...

if by monolith you mean a poorly architected spaghetti mess, then I agree, those should die.

microservices are "great" if you need them, but not if you only "need" them.

most apps that are developed will most likely see a major operational overhead of moving to a true microservices architecture. not every organisation is equipped to manage a complicated orchestration and discovery system.

I would wager that most organisations would be better served building "medium services" using microservice-like techniques (CQRS, vertical slices)

not every application is netflix and facebook
 
Last edited:
TStringList said:
What if a smaller app that doesn't require huge scalability?
Click to expand...
Then still build it as a micro-service, scalability is just 1 of its benefits. It will give you some hot skills in modern in-demand technology. And have some ambition, when your app needs the scaling then you don`t have to redev it from scratch.
 
_kabal_ said:
if by monolith you mean a poorly architected spaghetti mess, then I agree, those should die.

microservices are "great" if you need them, but not if you only "need" them.

most apps that are developed will most likely see a major operational overhead of moving to a true microservices architecture. not every organisation is equipped to manage a complicated orchestration and discovery system.

I would wager that most organisations would be better served building "medium services" using microservice-like techniques (CQRS, vertical slices)

not every application is netflix and facebook
Click to expand...
By monolith I mean the old world single monstrosity app architecture - spaghetti code or not. No, today micro-services is the tech of choice over the older monolithic monsters, we don`t need these anymore. And some "meduim service/micro-service" like does not sound like a good idea at all. I would not recommend your vertical slice implementation. Rather go for a true auto scaling serverless micro-service API endpoints. I am not sure what you mean by "manage a complicated orchestration and discovery system". Never heard of such a thing. Yes many businesses are "stuck" with their monolithic systems, future looks not so great for them.

If you are referring to Uber stuffing up their micro-services, yeah of course it is still possible to do it wrong.
 
Last edited:
:ROFL::ROFL::ROFL::ROFL::ROFL::ROFL::ROFL:







:ROFL::ROFL::ROFL::laugh::laugh::laugh::laugh::laugh::ROFL::ROFL::ROFL::ROFL:

Seriously you are talking out of your ass.
So now if we are not bowing to the serverless functions gods we are clueless? Got it.

never heard of orchestrating and discovery? Clearly never deployed more than a single “micro service”.
Hint: kubernetes, nomad, eureka, consul

Excellent way to derail a thread with tripe
 
Last edited:
Benedict A55h0le said:
Yes a microservice should have its own db, but we are talking EF here, not db. If an app has a db it does not mean that the app has to use EF.
Click to expand...
Duh. You can use whatever you want.

No one said you do have to use EF. This thread just happens to have been about EF.
You are the one who said that EF had no place in modern development, whatever that means
 
_kabal_ said:
:ROFL::ROFL::ROFL::ROFL::ROFL::ROFL::ROFL:







:ROFL::ROFL::ROFL::laugh::laugh::laugh::laugh::laugh::ROFL::ROFL::ROFL::ROFL:

Seriously you are talking out of your ass.
So now if we are not bowing to the serverless functions gods we are clueless? Got it.

never heard of orchestrating and discovery? Clearly never deployed more than a single “micro service”.
Hint: kubernetes, nomad, eureka, consul

Excellent way to derail a thread with tripe
Click to expand...
Nope not tribe. IBM and Microsoft is where I get my info from. And it so happens that the micro-service tech I use do not need a concept of discovery, and there is orchestration in what I use but this is what I am developing, its not some "thing that the business needs to manage", I manage it in code. Probably not the same thing we are talking about, maybe you should stop to know about everything and admit you dont know everything. This is not a derailment but just some good advice that I would give any dev who asks about EF. Rather ditch EF and do something cutting edge, especially if its a pet project. The job of a tech pioneer is tough.
 
Please enlighten us all to this cutting edge technology that will allow us to easily manage our db connection pools, transactions/UoW, query building, etc, with great speed and readability so that we can all ditch this legacy EF Core 5 which is clearly only suited for use in VB.net development.

I am being serious here, as I am on a constant pursuit of knowledge to add to my already incredible collection
 
Benedict A55h0le said:
docs.microsoft.com

Durable Entities Overview - Azure Functions

Discover what durable entities are and how to use them to manage stateful, distributed workloads in Durable Functions and Durable Task SDKs. Get started with examples and best practices.
docs.microsoft.com
Click to expand...
That looks really interesting thanks

Very keen to see some more real world examples and use cases above a Counter example - entities with complex state
Will investigate further.

Definitely not a replacement for a RDBMS. That would be like saying an event stream is a replacement for a database. They are solutions to different and sometimes similar problems.
 
Now I am derailing this thread, but I tend to fall down the rabbit hole when I see interesting things :giggle:

markheath.net

Azure Durable Entities: What are they good for?

Mark Heath's Development Blog
markheath.net markheath.net

This gave me a nice primer into potential UCs and when not to use :thumbsup: particularly interesting was the example of an in progress test or shopping basket

happy to discuss in another thread
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X