sir, you just got my voice ! 🫡

I'm focusing on my Domain design, and dictating what the Application layer can do with those repositories. You're missing the point, because "EF is a repository already" doesn't matter. You can use just EF, and you'll be fine. But that has other implications for your application.

i had thousand problems with tis method, dont use in large scale projects

This is a very unintuitive solution. No one expects to use the logic coded only in extension methods + by adding extension methods to DbSet which is a strictly EfCore class you tie your project to use EntityFramework only and you are not able to switch it to different project/database connector.

Seriously, this is like repeating the same argument over and over. Specific repository or generic are not silver bullets. Also, there will be projects you will come across multiple database providers, and the generic repository might be useful. Also, combining it with the specification pattern helps reduce the number of overloads for read commands.

How would this work if you wanted to mock out the db for testing and use in memory data instead of data in a db? In this case that you mention, you are stuck with using EF and a db

Very nice approach!

That's awesome. Which providers were you working with?

@@MilanJovanovicTech it was a tourism related company so they were APIs like booking, Expedia... We used that pattern to keep all the different information for all these providers in different tables

At that point - why not use EF Core directly?

Thanks a lot, glad you're getting value from the videos :)

Dapper one would be much more verbose on the implementation side - and we don't have a UoW 😁

Right, i use dapper in my project and have some repetition with the scenarios you solve in the video.

Dapper benefits from repository pattern much more than EF

i love that too, i am using dapper and i dont know how call the base repository method from my service, calling the specific repository interface with DI :S

Everything has a use case

My pleasure

Nice 👌

Haha! You're fast 😁

Will check to see how this works with MongoDb. Could possibly require some re-design. 🤔

Thanks a lot! Hope you found the other videos just as valuable 😊

Maybe we can look at it as "domain repositories" and "application repositories"? The naming might be a bit strange, but I think it describe what you/me are doing

@@MilanJovanovicTech Well that does indicate the difference.

thought the same thing. interesting approach but I would not put them in the Domain, good to hear I wasn't the only one thinking of that.

If you want that flexibility then yeah, go for it

Thanks!

Do you always want to include them, though?

@@MilanJovanovicTech when reading for modifying, yes! I've used another set of dbcontexts with plain hasmany-relations for readmodels. Not sure if it's a good idea in the long run, but it has been ok so far.

Strongly Typed IDs: kzfaq.info/get/bejne/gsqigMd6xsipYaM.html

Sure thing :)

Configure them to resolve the DbContext form the factory? 🤔

@@MilanJovanovicTech So we wouldn't inject the repository with DI but instantiate it in the calling method with a created context? Or is there another way to make the repository use the created context, preferably with DI? Sry for the stupid question 😅 Because what I think the problem is, when having DbContextFactory in repository class, it always creates a new context for each repository method, but I would like the repository and the unit of work to use the same context. Maybe I'm just missing something

How do you "raise" a domain event?

Break it up into use cases? An idea

Overengineering at its finest 😁🔥

Yes, that's one of the drawback of ORMs. If you want to load an entity, it'll have all the columns. You could optimize it by manually fetching specific columns, but most of the times you wouldn't do this if your intent is to write back to the DB. If you are using an ORM for a query (read) than you will definitely only want to fetch the columns you need.

This is not an ORM drawback! In ef core you can do it how you like it! Either you project your entities onto a dto, and EF CORE will only select the columns needed. This is good for readonly operations! In this case however, when trying to do DDD, you want your aggregates to be fully loaded into memory, because the aggregates define your consistency boundary. The aggregate can now use all the information in the aggregate to validate the operations your doing on it! If this means pulling too many unwanted columns from the database, maybe your aggregate is to big? Maybe it holds many unrelated fields, that don't have to be inside the same consistency boundary?

Maybe this: kzfaq.info/get/bejne/qtBljaal2828e40.html

It's something I've done in future videos, more or less

Just because it's anemic doesn't mean it's wrong. Some parts of the Domain simply won't have any behavior. Take a look at this for static data: kzfaq.info/get/bejne/rJyTjLeUqsy-aHU.html

Repository doesn't do writes, just adds stuff to the repo. UoW takes care of write. I don't think async (Task) in domain is bad, anyhow. The repository dictates the usage (not the implementation).

I asked this to GPT and this is the answer. But it is still not a good answer for me. When using the Entity Framework (EF) in .NET, the DbContext class already provides a SaveChanges() method, which might make it seem redundant to wrap this with a UnitOfWork. However, implementing the UnitOfWork pattern can still be beneficial, even if all you're doing is calling SaveChanges(). Here's why: Abstraction: UnitOfWork abstracts the underlying data access logic from the rest of the application. By doing so, it makes your application less dependent on a particular ORM or database technology. If you ever need to change your data access logic or even switch to another ORM, you'll have a single point of change. Testability: With the UnitOfWork pattern, you can mock your unit of work in unit tests. This makes testing easier, especially if you want to test services that have database interactions without actually hitting the database. Multiple Data Sources: In more complex applications, you might be dealing with multiple databases or data sources. A UnitOfWork can help manage transactions across these different sources. Decoupling: It allows services to be decoupled from the specific persistence mechanism being used, making the architecture cleaner and more maintainable. Flexibility: In the future, if you need to add more functionality around the commit (like logging, event raising, etc.), you can do it in the UnitOfWork without altering your service or repository classes. Transaction Management: The pattern can simplify transaction management, especially if there's a need to handle custom business transactions that span multiple operations or repositories. Clarity: By using the UnitOfWork pattern, you're signaling to other developers that you're aggregating operations for eventual transactional persistence. This can help in understanding the application's flow and logic.

Would you make each repository method also go to the DB?

​@MilanJovanovicTech Isn't that the main responsibility of a repository? Your get methods already access the DB. Excluding SaveChanges from the repository and renaming it to UnitOfWork outsources transaction handling to application logic.

@@MilanJovanovicTech i feel you, i've never thought uow like that, thanks you :) love your content :)

​@@Greenthum6I guess because you don't really know how many repositories you wanna touch before committing the transaction.Even though most often you'd only want a single aggregate to participate in your transaction.

Will they need repositories at all? Composite keys are a bit complex, so probably a slightly different solution

I'd be careful with expanding the interface like that, but it should be fine

I'm on the same side of the fence: repositories should only work with domain entities

I strive to send one command per request

@@MilanJovanovicTech But then if i want to create specific command need to create a lot of diff commands. But better in conroller call multiply small comands and after that call commit

R#

Multilevel what?

@@MilanJovanovicTech Multi children entities

Well, nothing really. You can't remove it from the base class.

1) can we write : throw NotImlementedException in child repository classes, to suppress not required methds of base Generic repo class? 2) If not then, this Generic repository approach is not usefull where only writing method (POST) is there. Forex: in case of some business transations, having only adding new records into db table is enough. Plz give your comments

@@ravindranaths513 Throwing NotImplementedExceptions is only for methods that are yet to be implemented (and _will_ be implemented). They should never be thrown purposely otherwise. In this case you'll simply get the methods for free within other repositories too, even if you don't (currently) need them 😉

So either go for everything - or use something like a specification pattern

@@MilanJovanovicTech You could use the specification pattern but that doesn't necessarily address the issue. Depends on the implementation.🙂 In a real world example a repository method can and should be able to be used by multiple consumers. But rarely they have the exact same needs when it comes to includes.

@@Benke01 Then just let the repository offer multiple variants of the method, either by adding an additional parameter or just create a few extra methods that include specific things.

@@kp_xcess That would quickly escalate to multitudes of methods. And their naming... 😥

Remember that you always use the repo interfaces defined at the domain layer. You don't have access to the members of the implementation so you won't see the generic repo methods.

1 - I explained that in the video, in-depth with my reasoning 2 - The repository implementation is internal - you're working with the interface

Nema na čemu :)

There are sequential GUIDs and ULIDs without the drawbacks. But GUIDs are mostly fine (albeit random). And in a distributed system you have to use something like that.

Don't mention it :)

Did you use it before?

@@MilanJovanovicTech Yes, it avoids having to write repeated code in the repositories and it allows you only to write specific queries only for certain entities

Not quite. Because the interface isn’t exposing the methods, they cannot be accessed outside of the Infrastructure layer. The domain & application layer will only use the interfaced methods :)

You can argue that you most likely always need CRUD actions on an entity. But I do get our point. There are definitely scenarios where you don't need the full CRUD actions.

@@TheFeljoy I mentioned only interface methods . Dont get your point.

@@Forshen So Milan said that he does not like it because all repo's get access to full crud , but we can dont need it . And than make same stuff.

I'm not worried about having these methods in the implementation, since they aren't exposed to the consumer

Thanks!

In the description

That rule is too constrictive for most applications

Might be better off creating a concrete method for complex queries

Patreon

And how would you do that?

@@MilanJovanovicTech don't make custom repositories like OrdersRepository or SalesRepository etc. Just make a generic Repository by using specification design pattern.

Same result, but I don't like using Find. Prefer writing my LINQ condition

Honestly, you should try avoid using Stored Procedures if possible.

@@Code_Bits can you explain why ? I have UnitOfWork with Generic Repository and I thought with Stored Procedure you can avoid sql injection?!? So what do you suggest?

How will you run into SQL injection with EF?

@@MilanJovanovicTech so what do you suggest? Leave just EF in my project without Stored Procedure? It's better ?

@@attilaguba856 I think the first Google search would answer your question honestly.

As a scoped service -> services.AddScoped()

@@MilanJovanovicTech i mean doest have to be the same dbcontext, used in the repository class or two scoped instances are ok, one to do the databas access one will do the save changes. What I had before a method within the abstract reposotory class, this method will do save changes.

Yes, the outer layers can reference the inner layers.

- www.milanjovanovic.tech/blog/clean-architecture-and-the-benefits-of-structured-software-design - www.milanjovanovic.tech/blog/why-clean-architecture-is-great-for-complex-projects

I share the source code on Patreon

Yes, in some versions. The versions before that (and after) are fine

It also wasn't really secret, they weren't caught, they announced it

Now you're reaching... I think it's still doable, but the GetById method would need to be updated slightly on the key filtering part

No - it's the other way around. Persistence can reference Application/Domain

@@MilanJovanovicTech ok, but if one may want to keep both layers independent of each other then in which project domain and DB entities should be mapped to each other and what would be appropriate way of mapping them?

LOGITECH G413 CARBON

Thanks!

I explained in the Domaim events video this specific problem, and how to solve it

@@MilanJovanovicTech I'll take a look!

@@MilanJovanovicTech This? kzfaq.info/get/bejne/eM-dmaeWqbyYqYk.html Because it only briefly touches the transactional outbox at the end. It seems like you have solution for this without transactional outbox hidden somewhere, but I can't find it, nor understand how it would work. :)

Oh. This one? It is just as problematic as it was before introducing events, only now the chain of events can be basically infinite and crash anytime? Transactional outbox is the only way, as I see it. kzfaq.info/get/bejne/d66qiq2QuLPVfKM.html

@@svorskemattias This one kzfaq.info/get/bejne/jqd8qdGJnLO0laM.html 😅😅

I share the code on my Patreon

Sigh... Didn't I explain it in the video?

@@MilanJovanovicTech No, I'm talking context. You explain why you use it. I am asking why not use it in a specific way, as all you're doing is recreating functionality that is already available.

No, I share the code on my Patreon

You can directly use Entities without an concrete repository for them. So you'll only be able to use the Add(), Update() etc... methods for that specific entity. If you implement the repositories the way Milan implemented them you could also make these methods virtual and override them in your specific repositories if needed. At work we also used this implementation of the generic repository pattern and it's a very good way imho. We also used a IUnitOfWorkFactory to create the Unit of Work and retrieving from the dependency injection container the repositories we needed.

How that builder work? Got an example?

​@@MilanJovanovicTechI think there were some ideas with exposing Set() DbContext method (where TEntity is IEntity, of course) and some scoped caching of the built repositories in a concurrent collection (if the repo is needed again in the same request)

I personally root against it, since there could be more Entities than DbSets, which could lead to some runtime exceptions

@@MilanJovanovicTech I don't have an example unfortunately, however the Factory created an UnitOfWork instance with the right DbContext. This UnitOfWork instance was used to get repositories (like the Product repository) which only accepted domain entities and automatically mapped them to the DbEntity (in case of an Add()). In case of an any other operation like Update() etc we also passed in a domain entity which would update the DbEntity. The repository took care of mapping them and you only needed to have the mapping configured and the repositories registered in your DI container. This worked very well in our case since as you can guess you only needed to inject the factory within your classes and not the UnitOfWork and repositories.

👋👋👋

Tough

Fully agree!

Blazing fast, congrats! 🔥

What about code duplication?

@@MilanJovanovicTech Its nice to put an interface around things for many reasons! The repository is not reinvented by doing this. Its just getting a nicer packaging, communicating through specific interfaces what operations are allowed. Also, you gain mockability.

Thanks!