How to use the Repository Design Pattern in C# and ASP.NET

[@tutorialsEUC]

🚀 C# Progress Academy - Become a job-ready C# and Angular web developer to land your dream developer role: bit.ly/45vbPUg

[@imadabab]

This is by far the best video on the Repository Design Pattern in C# on KZbin. Thank you so much for sharing such valuable insights and explaining it so clearly. It’s been incredibly helpful!

[@maryamblri]

I have 8 years of experience in programming and I found this tutorial awesome. great job! please cover more design pattern like UOW and factory design pattern.

[@Asp.net_Developer]

Very informative and simplified context! ❤❣ I love this ...swear🤞 by next year march i will be finishing 2 years of experience in the work enviroment. so buying your courses is so neccessary for Juniours like me. I wish you can do Udemy curses, been searching for your courses on Udemy🙈

[@vishalpathak832]

I guess in complex scenarios we should use generics to avoid this many entity repository and then implement Unit of work pattern on top of the generic repository.

[@learndevtech]

❤ magnific. This is way underrated!

[@dmgj4946]

Should you add another logic layer between controller and repository?

[@赛尼木]

pattern repository and unit of work

[@usmanfarooq_dev]

What will happen if we have a complex business transaction where we are saving multiple entities in DB. How would we manage the SaveChanges method when we need a db autogenerated id of one entity as an input value for another entity in same transaction?

[@TheMezanine]

In case of multiples transactions, you might implement Unit Of Work on top of Repositories. The UoW will manage the DBContext and implement transactions: EXAMPLE: public class UnitOfWork : IUnitOfWork { private readonly AppContext _context; public IUserRepository Users { get; private set; } public IAddressRepository Addresses { get; private set; } public UnitOfWork(AppContext context) { _context = context; Users = new UserRepository(_context); Addresses = new AddressRepository(_context); } public UnitOfWork() : this(new AppContext()) { } public int Save() { return _context.SaveChanges(); } public void Dispose() { _context.Dispose(); } public IDatabaseTransaction BeginTransaction() { return new EntityDatabaseTransaction(_context); } } USAGE: using(var unitOfWork = new UnitOfWork()) using(var transaction = new unitOfWork.BeginTransaction()) { try { unitOfWork.Users.Add(new User(... User One ...)) unitOfWork.Save(); unitOfWork.Addresses(new Address(... Address For User One ...)) unitOfWork.Save(); unitOfWork.Users.Add(new User(... User Two...)) unitOfWork.Save(); unitOfWork.Addresses(new Address(... Address For User Two...)) unitOfWork.Save(); transaction.Commit(); } catch(Exception) { transaction.Rollback(); } }

[@gregorydeclercq2990]

If you use controller-service-repository and handle the logic in the service. You (should) never get those issues

[@Lonchanick]

marvelous!

[@luisgonzalez8877]

Excellent explanation, thank you a million. I noticed that you invoked the repository tier from the controller (presentation) tier. Is this a best practice? I believe that specific logic requires the presence of business logic; for instance, in your example, it could be for the update method...

[@HenningBerggren]

You could insert an application layer (often referred as use case layer) where you would implement all your business logic (critical and application logic), but this is merely for larger applications.

[@gregorydeclercq2990]

Are People using context in controllers?!

[@kriskata7653]

Okay but what If we use services? I mean this repository pattern does the exact same thing as having a service. So I don't think this pattern makes sense in this case.