Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unit Of Work #46

Closed
domainmurat opened this issue Sep 5, 2017 · 10 comments

Comments

Projects
None yet
7 participants
@domainmurat
Copy link

commented Sep 5, 2017

Why did not you use UOW in this project ?

@ardalis

This comment has been minimized.

Copy link
Collaborator

commented Sep 5, 2017

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?

@domainmurat

This comment has been minimized.

Copy link
Author

commented Sep 6, 2017

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

@yarrgh

This comment has been minimized.

Copy link

commented Feb 20, 2018

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();
@abuassar

This comment has been minimized.

Copy link

commented Feb 27, 2018

@yarrgh : by doing this you sacrificed having explicit dependencies

@yarrgh

This comment has been minimized.

Copy link

commented Feb 27, 2018

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

This comment has been minimized.

Copy link

commented Feb 27, 2018

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.

@yarrgh

This comment has been minimized.

Copy link

commented Feb 27, 2018

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

This comment has been minimized.

Copy link

commented Jul 11, 2018

@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

This comment has been minimized.

Copy link

commented Aug 10, 2018

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

@ardalis

This comment has been minimized.

Copy link
Collaborator

commented Aug 12, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.