Once you have a complex system or lots of users, one should use E/R (such as iBatis) so that you can have fine grain control of the SQL.
Some developers think that one can solve data model layer issues in Java. The more complex the system or the load, the more you need to master SQL.
.V
Mathew Ring wrote:
Two comments:
1) I'm using Ibatis SQLMaps on a smallish web project and they're great. I had a basic persistence layer working in an hour. I think they're a good middle ground between JDBC and full-on O/R mapping. Sometimes working directly with the SQL is an advantage, especially when dealing with complex queries or DB-specific features. They do have trouble with CLOBs and BLOBs, though, but that may be partly due to Oracle's JDBC driver.
2) That being said, for a full-on O/R mapping solution, Joe's suggested path sounds really good.
Matthew S. Ring
-----Original Message----- From: Joe Hertz [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 2:36 AM To: [EMAIL PROTECTED] Subject: SV: ORM Tools (Ibatis, Hibernate, OJB....)
Eh, Middlegen and the Hibernate CodeGenerator are a good places to get an idea of what you are going for, but if my experience is any indication, I wouldn't use them for "the real thing", not without a really good refactoring tool.
For starters, at least against a MySQL database, MiddleGen didn't capitalize the classes it generated the way I would have wanted, it gave me clas names like "Myclassname".
That and there's only so much it can glean from the database schema. So if you "over declared" some field widths, plan on it typing your decimal(11,2) fields as java.math.BigDecimal, etc.
My "beat the learning curve" suggestion would be to do this:
Use the tools in order see something *like* what you are going for. The syntax will be right. The classes will probably have the getters and setters right at least (not any initializations).
Once your classes are at least looking more or less like what you would expect, and that you kinda understand what tht hbm.xml files *should* look like, go back and comment the classes with XDoclet Hibernate tags and build the .hbm.xml files that way, comparing the old and new xml files to see if you missed anything.
Can't say enough about XDoclet. As anal as Hibernate is about these xml files, some stuff does get through. XDoclet isn't nearly as picky, but very little can get past both (example: Hibernate will let your class have an int property and the corresponding .hbm.xml file have an "Integer". XDoclet won't let this happen.
HTH,
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
