Please see the DDL below:

create table Person (ID identity not null, varchar(name), Gender char(1), dateofbirth datetime, primary key (id))
create table PersonOffer (PersonID int not null references Person(ID), OfferID int not null references Offer(ID))
create table Offer (ID identity int not null, description varchar(20), primary key(id))

There is a many to many relationship between Person and Offer. PersonOffer is the junction table.

The Person class contains a List of offers because there are true invariants between the Person class and the offer class e.g. if the gender or date of birth changes, then the eligibility for offers changes.

I am trying to decide whether to use the UnitOfWork pattern here. As there is only one aggregate root (Person), then their should be one respoistory (PersonRepository). Therefore I do not believe I need to use the UnitOfWork pattern.

Q1) Should the PersonOffer persistence be done in the PersonRepository? Something like this:

foreach (var offer in Person.Offers) db.dbOffers.Attach(offer);

Q2) Do I need a Unit Of Work here?

The code in the repository creates a new Person with a List of offers as shown below:

public int Create(Application businessApplication)
            dbApplication dataApplication = Mapper.Map<Application, dbApplication>(businessApplication);
            foreach (var offer in dataApplication.dbOffers)
                return db.SaveChanges();
  • What sort of work would your proposed Unit of Work perform? Commented Jul 17, 2017 at 15:32
  • @Robert Harvey, once a user (person) registers, they are presented with Offers. Therefore the unit of work will write to two tables i.e. Person and PersonOffer.
    – w0051977
    Commented Jul 17, 2017 at 15:34
  • Substitute the words "database transaction" for "unit of work," and see if that makes sense. Commented Jul 17, 2017 at 15:35
  • @Robert Harvey, I believe you are saying that it would make sense to use UOW in my scenario as a db transaction is needed. Is that right?
    – w0051977
    Commented Jul 17, 2017 at 15:37
  • Read Fowler's unit of work description: "A Unit of Work keeps track of everything you do during a business transaction that can affect the database. When you're done, it figures out everything that needs to be done to alter the database as a result of your work." Essentially, you need a "unit of work" if the work you are doing must be treated atomically, i.e. as a single unit. Commented Jul 17, 2017 at 15:40

1 Answer 1


According to Microsoft, DBContext.SaveChanges already implements a Unit of Work. It does this by wrapping the entire operation in a database transaction.

Further Reading
Entity Framework Working with Transactions

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.