c# - In CQRS, should my read side return DTOs or ViewModels? -

i'm having debate coworkers in design of read side of cqrs application.

option 1: application read side of cqrs application returns dtos, e.g:

public interface iorderreadservice {     public orderdto load(int id); }  public class somecontroller {     public actionresult someaction(int id)     {         var dto = objectfactory.getinstance<iorderreadservice>().load(id);         var viewmodel = mapper.map<orderdto, someviewmodel>();         return view(viewmodel);     } }  public class someothercontroller {     public actionresult someotheraction(int id)     {         var dto = objectfactory.getinstance<iorderreadservice>().load(id);         var viewmodel = mapper.map<orderdto, someotherviewmodel>();         return view(viewmodel);     } } 

option 2: application read side returns viewmodels, e.g.:

public interface iorderreadservice {     public someviewmodel loadsomething(int id);     public someotherviewmodel loadsomethingelse(int id); }  public class somecontroller {     public actionresult someaction(int id)     {         return view(objectfactory.getinstance<iorderreadservice>().loadsomething(id));     } }  public class someothercontroller {     public actionresult someotheraction(int id)     {         return view(objectfactory.getinstance<iorderreadservice>().loadsomethingelse(id));     } } 

from research coworkers , have done on matter, responses appear mixed - looks depends on context. ask you, dear stackoverflowians:

does 1 approach seem have clear advantages on other? if so, they?

the general advice one projection per screen (greg young) or one projection per widget (if understand udi dahan correctly).

to consolidate read models dtos once again have mapped separate views contradicts whole purpose of optimized read model. adds complexity , mapping steps tried rid of in first place.

my advice: try close possible select * viewspecifictable [where ...] or similar if using nosql in thin read layer.

the concept of aggregate roots , "children" doesn't have of implication on read side, since these domain model concepts. don't want have domain model on read side, exists on write side.

ui platform-specific transformation mentioned mohamed abed should done in ui layer, not in read model itself.

long story short: i'd opt option 2. not confuse platform-specific viewmodel, i'd rather call readmodel have 1 per view anyway.