CODEWITHSUNDEEP
c#entity-frameworkdesign-patternsrepositorydto
Alexandre Perez
Alexandre Perez

Reputation: 3495

Can I return DTO from my repository in some cases?

I have two entities in my "domain assembly".

Message
- Id
- Title
- Content
- IsMandatoryReading

MessageUser
- MessageId 
- UserId        // The user who already read the message

In my "Infrastructure assembly" I have the MessageRepository with the methods Save, Delete, GetAll, GetMany, FindById etc, all refer the entity Message.

Now, I want to show to the user all messages marking those that he not have read it. So, I create the method:

public ICollection<MessageToUserDto> GetMessagesToUser( int userId ) { ... }

The only difference between the entity Message and the DTO MessageToUserDto would be the "IsRead" property which would determines whether the message was already read by the user.

DTO:

MessageToUserDto
- Id
- Title
- Content
- IsMandatory
- IsRead

I read in somewhere that is not a good idea using repository to return DTO.

But what would be better in this case? I need worry about this approach? I'm doing something wrong?

Upvotes: 0

Views: 1676

Answers (1)

pid
pid

Reputation: 11607

The concept of DTO actually origins from the DAO pattern which has been obsoleted in DDD (Domain Driven Design) by the concept of Domain Object.

This means the pure Repository pattern of DDD recommends to return a Domain Object, which actually means a POCO Entity if LinQ and persistence ignorance are desired (which is the recommended approach for DDD in C#).

This means you just have these POCOs and use them in the role of DTO to pass data between layers, for persistence in LinQ inside the repository and as parameters to the repository itself.

This uniformity across all uses is a desired quality and enables otherwise impossible ease of refactoring, readability and clarity of code.

If you need to add behaviour (as in MessageToUserDto) don't forget that you can derive a POCO from another...

Upvotes: 3

Related Questions