score:0

I use LINQ to map domain objects to view models. (I use the Entity Framework, but the technique works in any ORM with good LINQ support.) First write a POCO view model, then project onto it:

var pm = from c in Context.Cities
         let score = c.Scores.Where(s => s.MonthCode == selectedMonthCode).FirstOrDefault()
         select new CityScoresPresentation
         {
             City = c.Name,
             Score = score.Score
         };

This is LINQ to Entities. LINQ to SQL works similarly. YMMV with other ORMs LINQ implementations.

I strongly recommend using a view model instead of binding views to ORM-aware types.

score:2

We actually practice a form of Command Query Separation (Greg Young version -- not the Meyer version) so we would at the very least use the NHibernate ICriteria to select the details we want and then use the AliasToBeanTransformer to inject them directly into a DTO.

For our most complex entities we actually have a separated table with all the details a screen needs to display collapsed into a single row (aka OLAP). We can then run queries directly against this table which by-passes the cost of loading a complex entity which contains much more information then our screen needs.


Related Articles