3

In a DDD pattern should the unit of work be coupled with the repository? I've seen several different examples, including a repository that implements a unit of work interface, a repository that implements the behavior for unit of work itself, and a repository that has a property representing the unit of work so that it can be shared across multiple repository instances in the lifetime of the UoW. In the case of the latter, it kind of seems like an anti-pattern...that is, should a consumer really need to know to share an instance of UoW across repository instances? Shouldn't that be encapsulated and not exposed to the consumer?

I'd like to hear some input on the advantages of these different approaches over each other and why.

Thanks.

Jeff
  • 35,755
  • 15
  • 108
  • 220

1 Answers1

2

There's a discussion on this.

And I personally agree that UoW should be avoided completely. Same with generic repositories.

Community
  • 1
  • 1
Arnis Lapsa
  • 45,880
  • 29
  • 115
  • 195
  • So you support a service based strategy more than a repository one? That is, transaction at the operation level: service.Save(object), not using(var repo = new Repo()) { repo.Add(object); repo.Commit(); }? – Jeff Dec 13 '10 at 14:55
  • @JeffN825 I support idea that aggregate roots should define transactional boundaries. That way, scope would always be `repository.Save()` method long and You wouldn't need unit of work. – Arnis Lapsa Dec 13 '10 at 15:31