JavaWorld Forums: J2EE design decisions

I think both sides need to be considered equally in order to determine which approach is best (choose the approach that's best suited to your application's requirements). Yes you make a good point that performance may be an issue with using an ORM lightweight framework such as Hibernate, but you forgot to mention caching in the argument as well. Hibernate provides caching mechanisms out of the box which may help to improve performance of an application and make it more scalable across user groups.

Here are some problems I see with the custom JDBC approach:
1. Increased development and testing time
2. Procedural and error prone development
3. SQL is only as good as the developer who wrote it
4. Database dependent, custom boiler plate code might not be portable (separate JDBC code for different databases)
5. Increased maintenance and support

Lastly, from my experience I think it's important to start with sound, object oriented design and regress and refactor as needed. I come from the schooling that the design of a J2EE application should not be based on performance ghosts that cannot be accuractely quantified or have not been realized yet in the application. I agree with your point that applications need to perform to the expectations of the user community, but what good is that if you're unable to maintain or enhance it easily because of poor design.

Post Extras

InfoWorld: Modernizing IT

JavaWorld: Solutions for Java Developers