| JavaWorld |
| (addict) |
| 01/27/06 04:20 PM |
J2EE design decisions
|
J2EE design decisions
| **DONOTDELETE** |
| (Unregistered) |
| 01/31/06 04:14 PM |
Re: J2EE design decisions
|
Hi. I'm pretty new with AOP Hibernate/JDO topic.
And I'm not really a Java Programmer, but i know enought the Theory about EJB/J2EE.
I need if you can clarify, some of this issues.
* EJB 2.0 its really obsolete? , only Would be used for distributed transactions?
Is it Usefull? In what scenario can you think on that?
* If a use POJO with any of this lightweight frameworks, Can i have all the habilities given for the container to old Entity EJBs?
Thanx in advance.
Sorry about the little english.
AC
| **DONOTDELETE** |
| (Unregistered) |
| 03/02/06 01:42 PM |
|
Re: J2EE design decisions
|
I can see why you would think EJB 2 is obsolete or at the very least, taboo after reading this article. Keep in mind the author also wrote a book that he needs to sell, so he is a strong advocate of the POJO approach. Given that, I'm not surprised he never mentioned anything about performance and that a JDBC approach will ALWAYS perform better than an object-relational mapping (persistence) approach. So, if you have a high volume application and like your job, you might want to seriously consider the performance aspect of the argument. The extra coding effort required is usally worth it, and not that much extra to begin with. Otherwise, be prepared to tell your boss how great and "OO" your code is as he boots you out the door for writing an application that can't handle any kind of load in the real world.
| **DONOTDELETE** |
| (Unregistered) |
| 05/30/06 01:14 PM |
|
Re: 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.
| **DONOTDELETE** |
| (Unregistered) |
| 02/09/07 04:26 AM |
|
Re: J2EE design decisions
|
The reasons that should convince me to abandon EJB+JDBC have many precondidions. Those pre-conds are not true in our organization. Let me clarify:
1. JDBC is tedious to write
No it isn't. Most of the code is in AbstractDAO class, including loading parameters to fetch the connection, fetching the connection and closing all the things that need to be closed. Every SQL stored procedure call from Java looks exactly same in the Java code and errors are very easy to spot there.
2. Increased development time
Maybe. I don't know where that increase comes from, since writing the DAO class (SQL procedure call) is very quick.
3. SQL is only as good as the developer who wrote it
Yes. And it actually is great. Our Java-developers don't write SQL. Database specialists write it and Java code simply calls procedures. Actually, everything else except calling stored procedures is strictly forbidden. Those same stored procedures are often called by several separate applications, even from different platforms.
In my opinion and our few year experience, this all seems to result in superior efficiency compared to using Hibernate or other O/R mapping tools. A few times some projects have tried Hibernate, Entity Beans and iBatis for example. The results have been a total catastrophe, according to both efficiency and maintainability of the code.
4. SQL code not portable
So what? Our database is the same as it's always been and the code will never be run outside of our organization. Secondly, by checking the actual code it can be seen that most of it actually does not use any vendor specific features, and is portable.
5. Increased maintenance and support
I don't get this. Who needs to be supported? In my opinion, JDBC is simpler to write than O/R mapping tools or AOP/POJO frameworks. And with JDBC, you dont need any cryptic configuration files. Simply switching on container-managed transactions for the EJB and telling the DAO which connection pool is to be used is the configuration you need to do.
I would say that JDBC with stored procedures leads to decreased maintenance instead. You can change the database and the stored procedures as long as the procedure interface doesnt change. The Java code need not be changed.
| **DONOTDELETE** |
| (Unregistered) |
| 06/27/07 05:53 PM |
|
Re: J2EE design decisions
|
Quote:
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.
FYI we were forced to eliminate Hibernate caching due to serious performance issues and the solution provided by the app. server vendor was to switch to JDBC.
| **DONOTDELETE** |
| (Unregistered) |
| 01/16/08 06:32 PM |
|
Re: J2EE design decisions
|
Hibernate is a black box! sometimes you don't know how it works!!!, hibernate maintenance could be a hard work. If you use SQL you can test you code directly and besides sql perfomance is upper to hibernate performance.
In my experience I think is better to use hibernate to save, update and delete and It's better to use native SQL o store procedures to retrieve database information.
Remember this when you use hibernate and you will have to retrieve a simple object, if you don't control the lazy flag you will be dead, becasue hibernate can retrives you all the database, ;-)
| **DONOTDELETE** |
| (Unregistered) |
| 01/21/08 10:20 AM |
|
Re: J2EE design decisions
|
I don't totally agree with your points...
1.) You are using stored procedures.. that probably have business logic build in them, then you are replicating your business logic both in your java code and sql... and probably you need to rewrite the validation code.. any change in business logic will take your double efforts.
2) Writing SQL procedures is quick...agreed..but debugging? --- even harder than java... and if database has inconsistent data .. the stored procedures can not provide exact error... if frameworks like Hibernate is used, we can enforce integrity constraints easily..
3) Yes SQL is written by DB specialist, but sql will be executed by JDBC call only.... any small mistake can cause java code to break and complete transaction is gone..
4) ok
5) We all need to support.... if you leaving your company after coding then the persons who joins later have to mess up with divided code...
| uttlylovely |
| (stranger) |
| 08/01/08 12:09 AM |
Re: J2EE design decisions
|
Quote:
J2EE design decisions
