0

I have found some old questions, but I doesn't really answer or clear my doubts.

Repository Pattern + Unit Of Work: it is from 2012, and they tell that really to the repository pattern is not needed nowdays. Really I would like to know if repository pattern implies always unit of work and another aspects. Anyway, it would be to know another opiniones more recents if really repository pattern is useful or not today.

DDD - the rule that Entities can't access Repositories directly: this is a good post, but it desn't talk about unit of work.

Also I have asked another questions that are not answered in this posts. So I open a new one.

I am reading some examples how to implement repository pattern, thinking in a DDD architecture.

The pattern is called repository pattern, but many of the examples that I have seen implement the both and it seems that it is a unit, it has no sense or it is not good to implement only repository pattern, that it is needed the unit of work too.

Here are some examples, that they have small difference but it is the same one to do:

https://learn.microsoft.com/en-us/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

https://www.youtube.com/watch?v=rtXpYpZdOzM

In this examples, they use the repositories through the unit of work, so they don't use directly the repository to say in some way (really the repositories are uses because they are properties in the unit of work).

So my questions are various:

1.- When it is talked about pattern repository, really it means repository and unit of work or there is in some cases where it could be implemented only the repository?

2.- If it is implemented the unit of work, is it recommended to access the repositories only throuth it? Because in this examples, it is posible, in the consumer, instantiate the repositories and the unit of work. Wouldn't it be better to avoid the consumer to can use repositories and only create the unit of work?

3.- In the second link that I put, in the video, it is said that the repositories shouldn't have methods like update, that this is not the responsability of the repository, but in most cases of another examples, I always see the update method. So is it really a bad practice to have an update method in the repository? In this case, if I don't have this method and call the complete() method of the unit of work, it will work because behind the interface, the implementation uses an OR/M, but if another implementation doesn't use it, I have to notify in some way that the entity was changed. I guess an update method is the most easy to do it.

Well, in summary, I would like to know if really means to have the unit of work too or not.

Thanks.

Álvaro García
  • 18,114
  • 30
  • 102
  • 193

1 Answers1

0

When it is talked about pattern repository, really it means repository and unit of work or there is in some cases where it could be implemented only the repository?

From Evans, 2004

Leave transaction control to the client. Although the REPOSITORY will insert into and delete from the database, it will ordinarily not commit anything.... the client presumably has the context to correctly initiate units of work.

So Evans considers them to be separable ideas.

Implicit in Evans's writing is the idea that the information of the domain model is stored in a single relational database; which means that transactions spanning multiple aggregates are fine, because the database ensures that information is persisted atomically. But when you start looking at alternatives to a monolithic SQL database, robust persistence is... tricky.

A lot of modern writing eases some of this by adding a constraint that aggregate boundaries and transaction boundaries are aligned. In this kind of a design, you might reasonably factor the transaction management into the repository facade.

As a reader, we have to be really careful that we understand the implicit constraints of the author's context.

it is said that the repositories shouldn't have methods like update, that this is not the responsibility of the repository, but in most cases of another examples, I always see the update method

Evans again:

The ideal is to hide all of the inner workings from the client (although not the developer of the client) so that the client code will be the same whether the data is stored in an object database, stored in a relational database, or simply held in memory.

There are a couple problems with this ideal

  • Collections simply held in memory don't have distributed failure modes like the other candidate implementations
  • When is the change I made visible to others is an important design consideration

So you end up with people choosing different repository interfaces depending on how/if they decide to address these issues.

The important idea to recognize here is that REPOSITORY is a pattern; something we expect to have different expressions depending on the system of forces at play.

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. -- Christopher Alexander, A Pattern Language (emphasis added)

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91