• Post Reply Bookmark Topic Watch Topic
  • New Topic

Fast-lane-reader pattern.  RSS feed

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Fast lane reader pattern circumvents activation of entity beans by 'going the other way around' i.e. by reading the property values of the entity beans directly from a backend database. Part of the FLR pattern is the value list handler pattern, chopping up the entire result set into managable 'page by page' chunks, using the underlying (scrollable) ResultSet, producing lists or collections of DTO's (Data Transfer Objects).
Here's the bit I don't like about this Fast Lane Reader pattern -- the 'pattern' (mind the quotes) used for actually accessing the backend database is a DAO (Data Access Object). All those DAO's hack or 'synthesize' a SQL statement together, knowing the actual *raw* table and *column* names; they submit this statement, given a connection and retrieve a result set.
What I'd like to be able to is, given the names of the entity beans and the names of their persistent properties, find a mapping or translation from those names to the 'raw' table and column names. But how should I accomplish that mapping?
Does this question make sense to anyone?
kind regards
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One way to prevent hardcoding SQL statments in DAOs is to store SQL statments externally in an XML file. Checkout J2EE BluePrints Petstore application vesion 1.3 for a working example.
If you are using BMPs, then using the same DAOs for fast lane reading makes sense. However if you use CMP, you are forced to write DAOs or other JDBC/JDO routines just for straight JDBC access. I am yet to come across an efficient way of doing this in a CMP scenario.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jos Horsmeier:
What I'd like to be able to is, given the names of the entity beans and the names of their persistent properties, find a mapping or translation from those names to the 'raw' table and column names. But how should I accomplish that mapping?

This is just a classic case of doing O/R Mapping thru the use of metadata. While this is certainly possible, though I wouldn't see way you would what to base this on Entity Beans names. I also don't know why you would do all of this extra work just for a few Fast Lane Readers.
FLRs should only be used in a limited capacity and should therefore not be much of a maintenance headache, since the majority of your persistance is happening elsewhere. I see no problem with hand-coding the a few FLR Mappers.

If you are using and abusing FLRs then maybe you should address your real problem, which is that your primary persistance method is too slow. There are options other than Entity Beans when it comes to persistance.
I digress... back to your original question. If you are insistent on not hand-coding SQL, instead of investing your time in writing a bunch of framework code just for the a few FLRs, why not take a look at JDO or dedicated O/R Mapping Products that do this for you? Here are two links you may be interested in: OJB and Castor.
[ January 24, 2003: Message edited by: Chris Mathews ]
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ajith and Chris: thank you for your replies. I'm still in the design phase and when I look at out customers' user requirements, most of those client apps simply must provide tabular views upon all that data. That's why I thought of the FLRs; and there are a lot of them because of all those different views our customers want to stare at. I'm talking about a lot of data here (> 1e7 rows per table), so simple findByXXX calls on the entity bean homes are out of the question.
kind regards
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!