Matthew Phillips
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
I often read Hibernate is great but all the cases I've seen were handling less than 50 tables...
Regards,
Pho
PJ Murray -
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Dave Clark<br />Senior WebSphere Architect<br /><a href="http://www.versant.com" target="_blank" rel="nofollow">Versant Open Access - JDO2 & EJB3</a>
Originally posted by Dave Clark:
If you choose to go with JDBC and a DAO approach, you'll need a separate DAO for each table for each database = 250 table * 3 databases = 750 DAOs!
<snip>
Rather than the JDBC approach, a JDO approach lets you simply manage a set of mappings for each of the tables, and if you've got some good visual mapping tools (<plug>like those in Versant Open Access</plug>you can simply manage 3 JDO workbench projects - 1 for each database. [/QB]
PJ Murray -
With regard to writing JDBC DAOs - I would never suggest doing that.
Originally posted by Tim Wilson:
I think I'd rather maintain 750 Java classes than 750 proprietary mapping files, visual tool or not!
Cheers,
Tim.
I've done this on more than one occassion. The reason: there were no other options at the time.Originally posted by Andy Grove:
I'm curious .. why was a code generator built in-house?
I believe Paul said that the tweaking would be required only had a code generator not been used.If a commercial generator . . . was used there wouldn't be the need to tweak the generated code.
Originally posted by Tim Wilson:
I think I'd rather maintain 750 Java classes than 750 proprietary mapping files, visual tool or not!
Dave Clark<br />Senior WebSphere Architect<br /><a href="http://www.versant.com" target="_blank" rel="nofollow">Versant Open Access - JDO2 & EJB3</a>
Dave Clark<br />Senior WebSphere Architect<br /><a href="http://www.versant.com" target="_blank" rel="nofollow">Versant Open Access - JDO2 & EJB3</a>
Originally posted by Tim Wilson:
I think I'd rather maintain 750 Java classes than 750 proprietary mapping files, visual tool or not!
JDO is in serious danger... the JCP has already voted against it and Sun as published a open letter saying that they want to put the spec into maintenance.
ORM is interesting technology but I'd recommend sticking to a simple DAO approach personally.
Cheers,
Tim.
PJ Murray -
Originally posted by Andy Grove:
I'm curious .. why was a code generator built in-house?
If a commercial generator (<plug>such as FireStorm/DAOlt;/plug> ) was used there wouldn't be the need to tweak the generated code (although we do allow customers to tweak the code generator itself if they want to change the way that code is generated).
Regards,
Andy Grove
CodeFutures
[ February 25, 2005: Message edited by: Andy Grove ]
kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Originally posted by Ken Krebs:
Programming JDBC directly is not advisable because it is too low level to be productive with.
PJ Murray -
Originally posted by Thomas Whitmore:
[QB]Hi Chris, PJ, TIm, people,
PJ's solution is nice because you can see it. And touch it, in the form of monolithic blocks of code. And modify it manually. All 750 classes worth of it...
PJ Murray -
Seriously? That's what you're going with? I prefer this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
|