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