Can repository pattern be used for loading of “partial entities”

Question

I'm trying to get better understanding of repository pattern in Domain Driven Design. All examples of repository pattern implementation are dealing with entities only. But what if i need to retrieve only some part of entity? For example, i have Client entity with large amount of properties. Can i define something like this in ClientRepository:

public IEnumerable<string> GetClientsNames() {  ...  }

of even:

class ClientBaseInfo       //includes some subset of properties of Client entity
{
    public string Name {get; set;}
    public string Surname {get; set;}
    public int Age {get; set;}
    public string Email {get; set;}
}

....

public IEnumerable<ClientBaseInfo> GetClientsBaseInfo() {  ...  }

The reason for such implementation is performance. Anyway i consider my code will become polluted with this kind of "partial entities". Is this approach used in some way in real-life projects? Or the only way to avoid loading heavy entities is splitting of table and its corresponding entity or something else?

EDIT: Yes, i'm talking about something like DTO. I doubt if repository is intended to deal with this kind of objects, or it is for business entities only. I can define a lot of different DTOs for specific situations, but can my code become too complicated? I have no answer, because i don't have enought experience. I would like to know opinion of somebody experienced.

Answer 1

For these kinds of queries the suggested approach is to use a read model (CQRS-style).

So you could implement a very thin query layer that returns as primitive a structure as would serve your purpose. In the c# world I opt for anything from a DataRow to a DataTable to a DTO (for more complex structures).

Remember that a read model does not imply eventual consistency and that your query side can be at any level from 100% consistency in same table / database to eventual consistency in another database.

So these kinds of queries do not have a natural fit to the repository pattern.

Answer 2

It always depends, as usual.

Your Business Logic should not be dependent on database structure.

It should represent your business logic. That means, that you need to be careful when you design your entities and their relations.

On the other hand it depends why do you need to load only a part of entity's properties.

Maybe you should change domain logic, if you have so many properties in a class?

Maybe you need Data Transfer Objects?

You can create DTO class, which would be a "simple version" of your entity just to transfer data?

UPDATE:

You can use dto's in a repository. There're some cases, that it's need (reports, etc. ).

Here're some examples on that for NHibernate

NHibernate QueryOver projections - projecting collections to DTO

Fill property of DTO with SubQuery in NHibernate Query

This approach is acceptable for a few cases.

If you need to use dto's all over your application, it means you need to change your domain layer.

Maybe you should divide your classes into smaller ones and load them separately.