Repositories with EF/EFCore

[B-1]

IBM and Microsoft disagrees with you. Microservices is a new architecture replacing the old way. Yes it might not be a perfect fit for everything, but it is a fit for most things, and it is a fit for all the business systems I have seen in 20 years. Many devs use this as an argument not to use it but the reality is that their skills are outdated.

No they don't. They push micro services as a fit for devops style environments which is the common architecture/lifecycle these days yes but you can find plenty of articles on both their sites that state its not the be all to end all.

 

[Benedict A55h0le not]

I am still curious as to what or how you are going to perform CRUD against your database entities. You need something to interact with your database.

Old .NET SQL Client

 

[B-1]

Please give examples of where monolithic makes sense. The big problem with Microservice adoption is tech dept, just too much work to redev the system, but it is still the preferred choice. This is what is called being stuck.

I have already given some examples. But building prototypes/POC's is one of them. Here getting the concept running and proving its value or lack of it in the least amount of time at the lowest cost is far better than building it acording to the newest shiny thing. Do you keep the final architecture in mind when building the prototype yes of course.

Next there are organisations that are not agile and value systems that are rigorously tested and guaranteed not to fail over fast iterative releases that make it easier to be innovative and adapt to market changes.

 

[Solarion]

Old .NET SQL Client

Was doing this until quite recently. Check back maybe 30 pages or so it's littered with me trying to create the "perfect" SQLClient pattern

I did not take well to EF, or should I say, took to it begrudgingly. Need it for job purposes.

 

[_kabal_]

Every app I build is a microservice.
Just so happens some of those apps only have 1 microservice

 

[Solarion]

I see ol Nick Chapsas is also at this point in time pondering these things.

There's a Github link in the vid for this project.

 

[Herr der Verboten]

This. Was on a project recently where the client wanted something that executes fast, can be rapidly deployed and wants an MVP soon.

They were sold an micro service architecture when in all honesty a stateless scalable monolith (modularised obviously) would've sufficed. That micro service architecture did nothing but slow down initial development, complicate the release pipeline and provided fokkol real benefit.

But we drink the koolaid and pad our CVs with buzzwords

I blame the usual suspect: Corporate Trying to sound Cool. I guess most of us has played bizzword bingo during one of their meet(up)s.

 

[DA-LION-619]

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.

Maybe that's the problem and not EF? Take a look at Microsoft.Data.SqlClient not System.Data.SqlClient.
You can have an ORM in a micro-service, I've deployed Az Functions with EF Core, I didn't have any issues scaling 'scale efficiently'

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

That's persisted to Az Storage, you pay for every CRUD transaction. Moving a file means copying the file then deleting it from the original location, you'd seriously recommend that type of cost for a pet project?

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.

You're solving imaginary scaling issues. You can use EF + Az SQL and deploy to a Web App. You can scale the App Service Plan vertically and horizontally without the buzz words and then if you really need to scale some functionality you can deploy a function.
Functions evolved out of Web Jobs, it's nothing fancy.

nice, queued for tomorrow, bedtime now

the biggest advantage to this architecture IMO is the less cognitive load on a developer fixing/finding bugs or adding a feature. There is some zen in knowing that what you change in your handler cannot change any other part of the system.
Obviously you need to take care, as you do have shared code.


some more repos for you to browse

https://github.com/jbogard/contosoUniversityDotNetCore-Pages (Razor Pages)

https://github.com/jbogard/ContosoUniversityDotNetCore (MVC)

100% this! I think Jimmy also describes it as 'feature' slice architecture.

Same

I'm gonna need to sit with this for a while maybe over the weekend. It's quite, quite different from the usual repo pattern. Well later

Jimmy also has his presentations on GitHub, https://github.com/jbogard/presentations
.

 

[Benedict A55h0le not]

You're solving imaginary scaling issues. You can use EF + Az SQL and deploy to a Web App. You can scale the App Service Plan vertically and horizontally without the buzz words and then if you really need to scale some functionality you can deploy a function.
Functions evolved out of Web Jobs, it's nothing fancy.

Functions are fancy af, this is probably the greatest thing that I have seen in 20 years, serverless limitless autoscaling pre-paid compute for dirt cheap. This is revolutionary and is a more modern technology than just deploying a web app, now that is old school. It evolved out of web jobs but what makes it great is serverless compute.

None of the above are buzz words, these are just great new technologies. Let me give you a real buzz word: VENDOR LOCK-IN!

 

[DA-LION-619]

Functions are fancy af, this is probably the greatest thing that I have seen in 20 years, serverless limitless autoscaling pre-paid compute for dirt cheap. This is revolutionary and is a more modern technology than just deploying a web app, now that is old school. It evolved out of web jobs but what makes it great is serverless compute.

There are limits, it's literally in the docs. Don't read what you want to read, Azure Functions scale and hosting | Microsoft Docs
Pre-paid? I assume you're referencing an App Service Plan which means there's no cost difference between a function app or web app, also no difference to CI/CD.

/inb4 IBM and Microsoft disagrees with you. LOL

 

[_kabal_]

Functions are fancy af, this is probably the greatest thing that I have seen in 20 years, serverless limitless autoscaling pre-paid compute for dirt cheap. This is revolutionary and is a more modern technology than just deploying a web app, now that is old school. It evolved out of web jobs but what makes it great is serverless compute.

None of the above are buzz words, these are just great new technologies. Let me give you a real buzz word: VENDOR LOCK-IN!

Azure Functions Durable Entities.....






Vendor lock-in is another concept that is basically a non-issue for everyone.
Wrote an app in C# - that app is now locked into C#/Microsoft
Using an SDK to interact with a 3rd party service - you are now locked in (but but abstractions)


Vendor lock-in is as valid as choosing an ORM because it will allow you to, maybe, at some point in the unknown future, switch from SQL Server to Oracle - this literally never happens, and if it does you deal with it

 

[Hamster]

VENDOR LOCK-IN!

It's like we're going in circles. The industry can't help itself.

 

[TStringList]

Microservices is a new tech that is replacing monolithic ways. It is not simply 1 or the other. Today you 1st need to find a real reason not to use it.

This is exactly the thinking I am trying to avoid. The tools selection should come after the problem not before it. Sure, Microservices may fit many use cases, but it's not a one size fits all. Neither is Monolithic or Decentralised.

 

[quovadis]

Microservices is a new tech that is replacing monolithic ways. It is not simply 1 or the other. Today you 1st need to find a real reason not to use it. "The additional complexity and moving parts should be kept in mind, especially regarding long term maintenance, training new devs, cost" - these are benefits of Microservices not disadvantages. long term maintrnace is much easier, the business can respond better to changes, its less complex in that services are loosely coupled, and exposing devs to new tech is great and is actually a responsibility of the company. Cost is much better as well once you have it in place. You can choose to stick to the old ways but that is like saying stuff technology.

I think you have an overly-simplistic view. Microservices imho is mainly about distribution and scalability for meeting demand at scale. It's not a replacement for other approaches but is complementary in nature.