Unit Of Work

[muratcanoguzhan]

Why did not you use UOW in this project ?

[ardalis]

There was no need in the v1 sample. There may be more complexity that would warrant it in the v2 sample. Is there a specific instance in the sample where you would want to see it, or are you just looking for guidance on how to implement the pattern?

[muratcanoguzhan]

Yes @ardalis , How Can I implement uow design pattern in eShopOnWeb. Whats the best way for implement without compromising the project structure.

[trevor-hackett]

I like to create a generic method to ask for a repository. Internally it uses the ServiceProvider to inject/return a repository.

Something like this:

public interface IUnitOfWork
{
    IRepository<T> Repository<T>() where T : BaseEntity;
    int Complete();
}

public class UnitOfWork : IUnitOfWork
{
    private readonly SomeDbContext _db;
    private readonly IServiceProvider _serviceProvider;

    public UnitOfWork(SomeDbContext db, IServiceProvider serviceProvider)
    {
        _db = db;
        _serviceProvider = serviceProvider;
    }

    public IRepository<T> Repository<T>() where T : BaseEntity
    {
        return _serviceProvider.GetRequiredService<IRepository<T>>();
    }

    public int Complete()
    {
        return _db.SaveChanges();
    }
}

I've modified the repository classes to not update the database on add and remove and completely removed the update method. The UnitOfWork is responsible for these actions.

You can use it like this:

var usersById = new UsersByIdSpecification(new [] { 1, 2, 3 });
var userRepository = unitOfWork.Repository<User>();
var users = userRepository.List(usersById);

users[0].Name = "George";
users[1].Name = "Sally";
userRepository.Remove(users[2]);

unitOfWork.Complete();

[MuhAssar]

@yarrgh : by doing this you sacrificed having explicit dependencies

[trevor-hackett]

Not sure what you mean. If you don't like the UoW knowing about the ServiceProvider, you can always leave that dependency off and remove the repository method. From there you'd just inject your repositories along with the UoW in your controllers/services. Or just inject the repositories into the UoW and expose them as properties.

[vertonghenb]

Why do you want to use the UoW pattern? Behind the scenes EF is already using a UoW Pattern (SaveChanges). For some more details you can follow this tutorial: https://cpratt.co/generic-entity-base-class/
However I'm not sure I would recommend this implementation since it would break the idea of DRY(Don't Repeat Yourself) and the SRP (Single Responsibility Principle). But it will help you understand why you don't really need another Unit Of Work Pattern in this case.

[trevor-hackett]

Why I like using the UoW pattern:

https://programmingwithmosh.com/entity-framework/common-mistakes-with-the-repository-pattern/

A pattern that goes hand in hand with the repository pattern is the unit of work. With the unit of work, we can re-write that ugly code like this:

orderRepository.Add(order);
shippingRepository.Add(shipping); 
unitOfWork.Complete();

Now, either both objects are saved together or none are saved. The database will always be in a consistent state. No need to wrap this block inside a transaction. No need for two separate calls to the Save() method!

Yeah, you could use transactions to have the same effect, but I'm terms of simplicity, this is my preferred solution.

If you don't need this functionality, then don't bother with the pattern. That's my opinion.

[sheng-jie]

@yarrgh No matter what, I agree with you. In ddd, I prefer use UOW to manage repositories to ensure the consistent state of aggregate.

[kuacci]

@vertonghenb , EF has UoW built in, but how about other ORM frameworks? ORM tech should separated from upper layer like Repository/Business Logic.

[ardalis]

@yarrgh shows some good implementation options. As I wrote, I didn't need one in the initial version, so I didn't both adding it to keep things simpler. EF has it built in, but even if it didn't, I'm not using EF's capability because I'm explicitly saving changes on each write event in the repository implementation. In a web/web API app it's often the case that you want to do very small, atomic tasks within a given request, and then return. In this scenario, the need for UoW is the exception-case. In more complex scenarios where you need it, you can create your own UoW implementation or you can create one-off data access methods that perform a group of tasks within a transaction or similar scope.