Should the repository layer return data-transfer-objects (DTO)?

I have a repository layer that i开发者_JAVA技巧s responsible for my data-access, which is called by a service layer. The service layer returns DTOs which are serialized and sent over the wire. More often than not, services do little more than access a repository and return whatever the repository returns.

But for that to work, the repository has to return an instance of that DTO. Otherwise, you would first have to map the data layer object that the repository returns to a DTO in the service layer and return that. That just seems wasteful.

On top of that, if creation of the DTOs happens in the service layer, something that might have been done before in one repository call and thus one database query, now has to happen with multiple repository calls in the service layer to 'compose' the final DTO. Unless of course I create a transport object for between the data and service layer that can contain such a composed object. Which then has to be mapped to a DTO. It just seems wasteful for the sake of purity. But it also feels wrong to have the repository layer return objects that just exist to be sent over the wire.

---

Short answer: No.

Long answer: repository is responsible for turning persisted data back to entities (models) and vice versa.

Model is a business Model representing a business entity. DTO on the other hand - while looks like Model - is concerned with transfer of the object between various environment and in essence is a transient object. Usually mappers are responsible for turning model into DTO.

---

So your repository needs to hydrate the entire entity even if it's not being used? This seems very inefficient. – ajbeaven Oct 29 '18 at 23:25

Couldn't you add methods to the repository interface for calls that don't need to hydrate the entire entity? I suppose that could lead to bloated interfaces, which is one of the main arguments against, I think.

To answer the question, I agree with the accepted answer of No. Repository implementations are in the persistence layer. The domain layer may need to retrieve deep or shallow objects from the persistence layer which knows nothing except the Interface it must implement. If the domain is constantly asking for a full refrigerator when it only needs butter, then maybe the Interface (or perhaps the data model) need some work.