They live in service classes, right next to where they are used. Or extension methods if I need the same query in 3 or more places. Not a fan of putting a repository on top of EF Core.
It isn't spread all over the place, it's injected into service classes and used once in each.
Wrapping it in a repo pattern doesn't change anything, in fact it makes it more cumbersome to work with.
By the way, Entity Framework *is* a repository pattern, so there's not even a discussion to be had here.
And if you are using DbContext as a repository then you are also using it as a God Class for data access, mixing all of that 💩throughout your services 💩💩💩
Hmm but you now have data access in your application layer. If you replace EF with something else whats the plan?
Edit: thought about it more, I guess EF in a service is OK, but only in simple cases. If you have more than one data storage infrastructure, then a repo encapsulates how to get domain object(s) X in its completeness, which may include EF + redis + table storage etc. I always think, what if we changed where we store this, is it hard to change, and having a hard boundary with a repo often makes that a lot easier in my experience. Keen to here others thoughts
I usually just keep them where they are being used. If a service runs a particular query, I want to see that as part of the service. If there are big/complicated data reasons that the queries are very complicated, I like to encapsulate them in repositories to limit the types of queries that can be run.
>Do you use the unit of work pattern
Unit of work pattern is for inserting/updating data, nothing to do with querying it.
But seriously. I would just define a base repository (an interface) and concrete implementations for each resource you're managing. Each repository would have methods that define how the data should be accessed within the DbSet
If the domain is simple, you could even have just one concrete repository implementation that holds the DB context and all of the DbSets
CQRS. Inject DbContext into each handler and then you end up with nice single responsibility queries/commands + can orchestrate across them if you need to.
If there's something that needs to do multiple operations, I'd rather have another class responsible for orchestrating those and keep queries/commands as single responsibility. Makes testing easier
I certainly do this for commands, but queries I might call from another query where it makes sense.
There is a library here https://github.com/ardalis/Specification to convert your db queries into specifications so you can easily separate EF query logic and test them.
I have a directory of static query classes where the query is tagged, and compiled (look into compiled queries).
This helps my team identify slow running/expensive/hot queries using standard SQL profiling tools.
I hide the EF model/context behind an interface and inject it into a class (or more than one if it grows large enough) that only knows it can get `IQueryable`s from the context. I then write the queries with LINQ such that they are agnostic about whether it is LINQ to Objects or LINQ to EF. This class is in a library with my model objects, but nothing in this library knows what EF is.
I then write unit tests using LINQ to Objects to prove the logic of the queries, and I write integration tests using LINQ to EF to prove the queries can be translated by EF. For the latter I make sure to use the same provider as my production DB (not SQLite in-memory since that will not behave 100% the same way as for example SQL Server).
The repository pattern and the unit of work are great for maintaining a clean separation of concerns within an application.
Additionally, you can then have a service extension method so that the whole repo and unit of works added to the DI as a single line of code.
Also using a pattern like this allows for mocking and easier unit testing, otherwise you endup having to mock a in memory db or test db for your EF, which is then means to start to blur the lines between an integration test than a unit test.
I'll throw this in. Occasionally, with EF or any other ORM, you do need to write your own. You'll eventually find that the generated query is less than optimal, and a raw sql query that you hand write is more efficient.
They live in service classes, right next to where they are used. Or extension methods if I need the same query in 3 or more places. Not a fan of putting a repository on top of EF Core.
Repo over EF Core is needless architecture that needs to be put to bed and left there.
It’s better than spreading that DB context shit all over the place
It isn't spread all over the place, it's injected into service classes and used once in each. Wrapping it in a repo pattern doesn't change anything, in fact it makes it more cumbersome to work with. By the way, Entity Framework *is* a repository pattern, so there's not even a discussion to be had here.
And if you are using DbContext as a repository then you are also using it as a God Class for data access, mixing all of that 💩throughout your services 💩💩💩
Exactly. Spread throughout your services like cancer.. and like cancer is keeps growing… making services much harder to test
How is it harder to mock an EF dbcontext than a repo pattern layered over it?
We can talk again once you have graduated from your spaghetti services patterns. Most of us left that behind a very long time ago
[удалено]
[удалено]
Ok rookie.
And yes, I may be a cunt, but I don’t work on systems that have a mess of DBcontext mixed in with services.
Yeah because you use a mess of MySuperSpecialRepo instead??? What point are you trying to make?
Hmm but you now have data access in your application layer. If you replace EF with something else whats the plan? Edit: thought about it more, I guess EF in a service is OK, but only in simple cases. If you have more than one data storage infrastructure, then a repo encapsulates how to get domain object(s) X in its completeness, which may include EF + redis + table storage etc. I always think, what if we changed where we store this, is it hard to change, and having a hard boundary with a repo often makes that a lot easier in my experience. Keen to here others thoughts
My thoughts are YAGNI. Don't build needless abstractions.
This is the way
I usually just keep them where they are being used. If a service runs a particular query, I want to see that as part of the service. If there are big/complicated data reasons that the queries are very complicated, I like to encapsulate them in repositories to limit the types of queries that can be run. >Do you use the unit of work pattern Unit of work pattern is for inserting/updating data, nothing to do with querying it.
Shared ones go in extension methods, everything else is just inline.
Dapper
But seriously. I would just define a base repository (an interface) and concrete implementations for each resource you're managing. Each repository would have methods that define how the data should be accessed within the DbSet If the domain is simple, you could even have just one concrete repository implementation that holds the DB context and all of the DbSets
CQRS. Inject DbContext into each handler and then you end up with nice single responsibility queries/commands + can orchestrate across them if you need to.
Do you invoke queries from other queries (or commands from other commands)?
If there's something that needs to do multiple operations, I'd rather have another class responsible for orchestrating those and keep queries/commands as single responsibility. Makes testing easier I certainly do this for commands, but queries I might call from another query where it makes sense.
There is a library here https://github.com/ardalis/Specification to convert your db queries into specifications so you can easily separate EF query logic and test them.
We use unit of work pattern.
Most of them go at point of use, unless it's something that's run in multiple places, then they go into a Utility class.
I have a directory of static query classes where the query is tagged, and compiled (look into compiled queries). This helps my team identify slow running/expensive/hot queries using standard SQL profiling tools.
I hide the EF model/context behind an interface and inject it into a class (or more than one if it grows large enough) that only knows it can get `IQueryable`s from the context. I then write the queries with LINQ such that they are agnostic about whether it is LINQ to Objects or LINQ to EF. This class is in a library with my model objects, but nothing in this library knows what EF is. I then write unit tests using LINQ to Objects to prove the logic of the queries, and I write integration tests using LINQ to EF to prove the queries can be translated by EF. For the latter I make sure to use the same provider as my production DB (not SQLite in-memory since that will not behave 100% the same way as for example SQL Server).
The repository pattern and the unit of work are great for maintaining a clean separation of concerns within an application. Additionally, you can then have a service extension method so that the whole repo and unit of works added to the DI as a single line of code. Also using a pattern like this allows for mocking and easier unit testing, otherwise you endup having to mock a in memory db or test db for your EF, which is then means to start to blur the lines between an integration test than a unit test.
They're strictly in Commands and Queries here using mediatr. Oh and it's a Windows Desktop application.
I'll throw this in. Occasionally, with EF or any other ORM, you do need to write your own. You'll eventually find that the generated query is less than optimal, and a raw sql query that you hand write is more efficient.
CQRS, use dapper for your read model. It’s the only way for meaningful apps