Question

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.

Answer 1

There’s a discussion on this.

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