Doesn’t it take a lot of code to turn the projection into valid SQL? A valid concern. The classical approach is to put the ORM in an XML file and interpret it over and over again. That is potentially more time-consuming than actually generating SQL.
The alternative is to interpret the XML model only once and generate some source code that is a more technical representation – ready to support the SQL generation. Also that’s a good moment in time to validate the mapping, the projections and all of that. Needless to say what my favorite approach is.

1. In you example what is the data type of an element in hotelList? Since projections can contain variable data its hard to see how it could be fixed data type. Is it an ado.net DataTable?

2. Doesn’t it take a lot of code to turn the projection into valid SQL? Or are you saying that your mapping software provides most of the code to do that so you don’t need to write the SQL generation code yourself?

I’ve never used an OR mapper so software so I’m I don’t know if application programs could access the SQL generator capabilities of the OR Mapping software directly.

Bill Hamaker

In practice, I start out with dynamic projections during early development of an application. By the time my data entry forms, my list pages and my view pages are all in production-ready state, I turn the dynamic projections into static projections by adding them to the OR mapping file and taking out all the setProjection() calls. Flexibility at development time makes way for performance at production time.

Examples of use:
with a static projection, client code must refer to a projection name that Repository knows about:
hotelList = hotelRepository.find(“hotelListProjection”, );
This throws an exception when “hotelListProjection” is not a known projection name.
With a dynamic projection, client code must first make the projection known to the repository, at which point it is validated:
hotelRepository.setProjection(“hotelListProjection”, “hotelName, streetAddress, qualityRating”);
hotelList = hotelRepository.find(“hotelListProjection”, );
The setProjection method throws validation exceptions when attribute names or association names are unknown to the repository.

The examples above discuss the use of projection for object population which is only part of the story. The other part is of course the object persistence, when object data must be passed back to a persitent store. Again, I’m using projection for that. Reason being that in typical interactive applications, the client code is very much aware of the attributes that were exposed to the UI so it knows very well which attributes may potentially have changed (it’s the same list of attributes that was used to build the data edit page in the first place, in the case of an “update” scenario).

Bert Hooyman, Utrecht, Netherlands

public List GetPeople(PersonProjection projection)

And the Person class would need to implement lazy loading to handle the case where the application references some attribute or method that relies on data not in the projection.

Is that correct?

If so I’m curious if you consider the PersonProjection class part of the domain model? And if not where does it reside?

I don’t see anything wrong with doing what you describe other than the fact that it is a very big front end investment. I find the idea rather daunting but its always nice to make investments if you can get enough reuse to justify them.

If you have just a few fixed projections then what you have done is not so different from what I did where I assumed there was typically each class had just one projection that the user cared about. Except I wasn’t willing to implement a lazy loading system so I suggested passing around an interface rather than a lazy loaded domain object.

If instead you are proposing that the user interface developer needs to construct generic projections in a general purpose query language then you have complicated the UI layer significantly.

Bill Hamaker

The consequence of this is that View becomes much more relevant than Model. Hence, the underlying code should provide support for delivering View-related information. I’m not a big fan of elaborate object models for view-only purposes (data carriers). Instead, I would be quite happy to push around the first-class domain model objects and live with partially populated attributes. I have worked on this approach and came to appreciate the value of attribute lists, which I tend to refer to as projections (an RDBM term). As an example, when I’m populating a pick list of hotels, and each item in the list would only show the hotel name, the street address and the quality rating, I would use a named projection that refers to an attribute list with those three attributes, plus an identifier of course. I would use a Repository with a generic finder method that accepts a query object as well as a projection name. It would ultimately turn the query object into a WHERE clause and the projection into a SELECT clause, assuming the repository accesses a regular SQL source. Projections need not be restricted to a single object’s primitive attributes; it may also work with embedded objects, for example various room types in the hotel. By the time my View tier needs details of a single hotel, including the standard rates for all room types, the projection would include roomtypes.name, roomtypes.rate, roomtypes.facilities as attributes. Those would come back as a collection of roomType objects, embedded within a hotel object.

The real benefit of projection-based object population with query-based finders is that your data access tier becomes extremely general-purpose (read: reusable). One implementation is usually enough for supporting all of the requirements of the View tier.