views:

34

answers:

1

I'm working on a 2-tier application where WinForms client makes direct calls to the database. In one of the scenarios I need to display a list of Customer entities to a user. The problem is that Customer entity contains a lot of properties (some quite heavy) and I need only two of them - first and last names. So to improve performance and make presentation logic clearer I want to create some kind of a CustomerSummaryViewModel class with required properties only and use NHibernate's projections feature to load it. My concern here is that in this case my data access logic becomes coupled with presentation and to me it seems conceptually wrong.

Do you think this is ok or there are better solutions?

A: 

I think you can consider the CustomerSummaryViewModel as report (CustomerSummaryReport). It is fine to query your entities for scenario's like this and treat them as reports. Most reports are more complex, using multiple entities and aggregate queries. This report is very simple, but you can still use it like a report.

You also mention that the performance is significant. That is another reason to use a separate reporting query and DTO. The customer entity sounds like one of the "main" entities you use. That it takes a significant amount of time to retrieve them from the database with lazy-loaded properties not initialized, can be a warning to optimize the customer entity itself, instead using reporting queries to retrieve information about them. Just a warning because I have seen cases where this was needed.

By the way, you can consider linq instead of projections for the easier syntax like:

var reports = session.Linq<Customer>()
  .Where(condition)
  .Select(customer => new Report 
   { 
       FirstName = customer.FirstName, 
       LastName = customer.LastName 
   })
  .ToList();
Paco
Thanks, Paco. Considering Presentation Model as report is coming from CQRS, right? :) I have very superficial knowledge of it, but from what you described I take it as "yes - it is ok to load PM directly from DB". I intentionally avoided using term "DTO", because in my understanding it's applicable in distributed scenarios, where data needs to be sent over the wire, which doesn't exist in 2-tier app.
Dev
With DTO, I just mean "dumb object". Using presentation model as report is something I did before I heard of the term CQRS, but it does fit into CQRS indeed.
Paco