Hi group,
I've been reading this group for a little over a month now and been playing with some
Castor test apps. It looks to me at this point that to use Castor in my environment
would be more difficult and slower than writing an EJB BMP type persistance layer with
hand coded SQL. It seems that the design of Casor works well with toy example apps or
small apps where the data model is tied closely to the application itself. If I'm
wrong in these assumptions please correct me.
Here is why;
*) Castor is slower than hand written SQL in Prepared Statements. Castor has to
interpret the OQL, map it to SQL and execute the SQL as a statement.
*) The design of Castor assumes that the database schema will make sense and be well
designed and therefor sortof closely map to the object layer. I have a 400+ tables
spread out over about 7 seperate Oracle schemas. Almost every query requires a
multi-table join.
*) For real world applications Castor seems to actually complicate getting data to and
from the database. It's great in a play app where the customer is in a customer table
and maps to a similar customer object. But in a real world app where I have to join a
location table, a representive table, perform a where on a range of dates and outer
join it to something else. Same issue when I update a table or insert. What if the
data in the program object is spread out over multiple tables?
It seems like Castor sounds good on paper but then you apply it to the complex real
world database schemas it falls apart.
If I'm going down the wrong path with my assumptions please someone inform me of my
ignorance. Otherwise I'm about to dump the whole concept for an object relational
mapping layer as not being realistic.
Thanks,
Tony
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
