Repositories with EF/EFCore

[Solarion]

Now I am derailing this thread, but I tend to fall down the rabbit hole when I see interesting things

Azure Durable Entities: What are they good for?

Regular readers of this blog will know I am a huge fan of Azure Durable Functions which provide you a way to define serverless workflows in code. My…

markheath.net

This gave me a nice primer into potential UCs and when not to use

happy to discuss in another thread

Keep going. Has piqued my interest too

Something along the lines of this possibly?

Durable Functions Overview: Stateful Serverless Workflows - Azure Durable

Learn how Durable Functions extends Azure Functions to build reliable, stateful workflows in a serverless environment. Get started with supported languages, storage providers, and quickstarts.

docs.microsoft.com

 

[Solarion]

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.

 

[_kabal_]

Yeah these durable functions look like a nicer/richer version of AWS Step Functions

 

[_kabal_]

I am still curious as to what or how you are going to perform CRUD against your database entities.

In .Net - EF Core, using the DbContext as your “repository”

think of the DbContext as a repository that provides a fluent api

if some part of your system wants to get customers order by age, and another wants them ordered by shoe size and another wants by shoe size asc, why do we need/want a class that exposes these 3 functions that are most likely used by 3 different things.
Things get even worse when a 4th thing uses one of those 3 functions as now if you want to change a condition or ordering you need to introduce ANOTHER repository method because you might break other functionality - not by compiler error, but by unwittingly changing behavior

 

[B-1]

There is no best way to do things. Each scenario dictates what would be the most efficient way. Monolithic architecture still makes sense in many scenarios. We all want shiny new micro services everywhere but you have to ask is this right for what I need to achieve here. Same with EF or any ORM really. Is the overhead worth it as a tradeoff? If yes then its the right tool for the job.

 

[_kabal_]

Just jack it straight into a service layer? A little concerned about separation of concerns (DB from Service). I guess with DI that could be resolved by just moving the service layer into the DB layer?

You only really need to create calls that are needed. How bloated can 1 service get? (If Im understanding this correctly)

essentially we don’t use layers in the n-tier sense

This would be a pretty simple but typical example of a Web API solution

Model
   DbContexts
   Models

Infrastructure
   Things that arent business-specific, but are needed.
   Basically "glue" code in a way. It references none of the other projects
   Generic extension methods to linq, eg ForEachAsync, PaginatedListAsync
   Maybe you need an abstraction to add messages to a queue e.g. IQueueService, RabbitMqQueueService: IQueueService
   Maybe you want to send emails. IEmailClient/Service, SendGridEmailService/Client


Application
   This is where the magic happens, and it starts with Feature folders. What's important to note is that this is all autowired
   Customers
      GetAll.cs //here you name space
         public class GetAll {
            public class Request {} //implements a MediatR request
            public class Model {} //yes, you can choose to use a shared model/response e.g your GetAll returns a list of the same model that your GetById uses. or you can duplicate, really depends
            public class Handler {} //implements a MediatR request handler
         }
      GetById.cs
   Invoices
       Approve.cs
       Reject.cs
       GetOutstanding.cs
   Orders
      GetByCustomer //alternate way to go a folder deeper and split classes into their own files
         Request.cs
         Response/Model.cs
         Handler.cs
         MappingProfile.vs
    
WebApi
   Controllers
      CustomerController.cs
         public class CustomerController {
            [HttpGet]
            public async Task<ActionResult> Get()
            {
                // ALL controllers end up following the same 2 line pattern, controllers become irrelavent, they convert an http request into a Query or a Command
                var result = await _mediator.Send(new MyQuery());
                return Ok(result);
            }
         }
   Startup.cs
   etc

So here is the crazy/controversial part - put EVERYTHING in your handler... WHAT!!! just try it

Standard clean code rules apply.
When smells appear, refactor, red, green.
Just because 2 things look that same doesn't mean they are the same.

 

[Solarion]

essentially we don’t use layers in the n-tier sense

This would be a pretty simple but typical example of a Web API solution

Model
   DbContexts
   Models

Infrastructure
   Things that arent business-specific, but are needed.
   Basically "glue" code in a way. It references none of the other projects
   Generic extension methods to linq, eg ForEachAsync, PaginatedListAsync
   Maybe you need an abstraction to add messages to a queue e.g. IQueueService, RabbitMqQueueService: IQueueService
   Maybe you want to send emails. IEmailClient/Service, SendGridEmailService/Client


Application
   This is where the magic happens, and it starts with Feature folders. What's important to note is that this is all autowired
   Customers
      GetAll.cs //here you name space
         public class GetAll {
            public class Request {}
            public class Model {} //yes, you can choose to use a shared model/response e.g your GetAll returns a list of the same model that your GetById uses. or you can duplicate, really depends
            public class Handler {}
         }
      GetById.cs
   Orders
      GetByCustomer //alternate way to go a folder deeper and split classes into their own files
         Request.cs
         Response/Model.cs
         Handler.cs
         MappingProfile.vs
   
WebApi
   Controllers
      CustomerController.cs
         public class CustomerController {
            [HttpGet]
            public async Task<ActionResult> Get()
            {
                // ALL controllers end up following the same 2 line pattern, controllers become irrelavent, they convert an http request into a Query or a Command
                var result = await _mediator.Send(new MyQuery());
                return Ok(result);
            }
         }
   Startup.cs
   etc

So here is the crazy/controversial part - put EVERYTHING in your handler... WHAT!!! just try it

Standard clean code rules apply.
When smells appear, refactor, red, green.
Just because 2 things look that same doesn't mean they are the same.

I'm going to

This looks to be quite similar, although he has everything split up into commands. I'm looking at his Github project now and recognize some terms you've used above.

Stop Using Repository Pattern With an ORM - Hamid Mosalla

In this post I'm goign through different reasons for using repostiry pattern and argue why it might not be necessary to use it and what can be used instead.

hamidmosalla.com

GitHub - HamidMosalla/FreelancerBlog: FreelancerBlog is a blog built with Asp.Net Core around the idea of hexagonal architecture and CQRS.

FreelancerBlog is a blog built with Asp.Net Core around the idea of hexagonal architecture and CQRS. - HamidMosalla/FreelancerBlog

github.com

 

[_kabal_]

I'm going to

This looks to be quite similar, although his handlers are all split up. I'm looking at his Github project now and recognize some terms you've used above.

Stop Using Repository Pattern With an ORM - Hamid Mosalla

In this post I'm goign through different reasons for using repostiry pattern and argue why it might not be necessary to use it and what can be used instead.

hamidmosalla.com

GitHub - HamidMosalla/FreelancerBlog: FreelancerBlog is a blog built with Asp.Net Core around the idea of hexagonal architecture and CQRS.

FreelancerBlog is a blog built with Asp.Net Core around the idea of hexagonal architecture and CQRS. - HamidMosalla/FreelancerBlog

github.com

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)

 

[Solarion]

owing 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.

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

 

[TStringList]

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.

I usually start with a problem and then choose an architecture to suite the solution. That being said, I usually default to a traditional DDD architecture whereas you seem to default to Microservices. I appreciate the value of Microservices but it would be wise to refrain from treating it like a solution looking for a problem (like block chain). The additional complexity and moving parts should be kept in mind, especially regarding long term maintenance, training new devs, cost, etc.

 

[Benedict A55h0le not]

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.

Not a replacement of a RDBMS system, but this is a tech that is new and is replacing/should be used to redev monolithic systems. Monolithic systems will be around for very long but this is only because companies are not agile enough to adapt.

 

[Benedict A55h0le not]

I usually start with a problem and then choose an architecture to suite the solution. That being said, I usually default to a traditional DDD architecture whereas you seem to default to Microservices. I appreciate the value of Microservices but it would be wise to refrain from treating it like a solution looking for a problem (like block chain). The additional complexity and moving parts should be kept in mind, especially regarding long term maintenance, training new devs, cost, etc.

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.

 

[B-1]

Not a replacement of a RDBMS system, but this is a tech that is new and is replacing/should be used to redev monolithic systems. Monolithic systems will be around for very long but this is only because companies are not agile enough to adapt.

I'm a big proponent of micro services but its not right for all businesses/departments. As you noted its a strong solution for an agile environments where quickly changing product focus and fast iteration is critical. But for things like POC's and slow changing mission critical systems that don't need much in terms of compute scaling monolithic is still a good idea.

 

[Benedict A55h0le not]

I'm a big proponent of micro services but its not right for all businesses/departments. As you noted its a strong solution for an agile environments where quickly changing product focus and fast iteration is critical. But for things like POC's and slow changing mission critical systems that don't need much in terms of compute scaling monolithic is still a good idea.

For some systems it is not as critical to upgrade to a modern architecture in the short term, but at some point they must upgrade, its not ideal to keep legacy systems going for too long.

 

[B-1]

For some systems it is not as critical to upgrade to a modern architecture in the short term, but at some point they must upgrade, its not ideal to keep legacy systems going for too long.

Micro services is not an upgrade its a design pattern and not right for every scenario.

 

[Benedict A55h0le not]

Micro services is not an upgrade its a design pattern and not right for every scenario.

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.

 

[Herr der Verboten]

View attachment 1031246

There is no best way to do things. Each scenario dictates what would be the most efficient way. Monolithic architecture still makes sense in many scenarios. We all want shiny new micro services everywhere but you have to ask is this right for what I need to achieve here. Same with EF or any ORM really. Is the overhead worth it as a tradeoff? If yes then its the right tool for the job.

but The New Shiny is always better than current, previous or old.

 

[Hamster]

C# has a way of pushing abstractions too far and some guys who drink too much koolaid go nuts with it and before you know it they end up with a parallel *.Abstractions project for every library they develop.

You should be able to rewrite that micro service in (close to) a single sprint anyway so all these abstractions and wrappers tend to get in the way...fluff I call them.

One area where they are useful, maybe, is unit testing, but that's debatable too.

 

[Benedict A55h0le not]

View attachment 1031246

There is no best way to do things. Each scenario dictates what would be the most efficient way. Monolithic architecture still makes sense in many scenarios. We all want shiny new micro services everywhere but you have to ask is this right for what I need to achieve here. Same with EF or any ORM really. Is the overhead worth it as a tradeoff? If yes then its the right tool for the job.

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.

 

[Hamster]

Micro services is not an upgrade its a design pattern and not right for every scenario.

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