Spring + Hibernate EJB3, POJO + JDBC?

In the beginning there was nothing: no Java and no data. Then someone said, let there be data and relational databases with SQL were born. And someone said, let Java talk to databases, and JDBC was born. And someone saw that JDBC was good, but someone else saw that JDBC was bad, and EJB with CMP were created. And someone said, J2EE containers are bad and POJO has resurrected. And entity beans were slow and heavy; Hibernate was born and people forgot SQL, which was a sin.

Reader Feedback: Page 1 of 1

#14	Jurgen Van Oosterwijck Blogs commented on 29 Nov 2006 Trackback Added: Frameworks vs JEE standards; Yakov Fain writes about the clash between POJO frameworks and standardized JEE. As far as I see it, the new JEE5 standards are a way of getting back some of the marketshare. Marketshare that was taken by Spring on one hand as the EJB alternative
#13	Yakov commented on 23 Nov 2006 I do not have negative attitude toward Spring - it's one of the best Java frameworks available today. But I do not see it as a revolutionary framework, just different. I do not think that it's a lot easier than J2EE when it comes to real world projects. Today's enterprise Java programming is overly complicated, which make projects more expensive to develop than they need to be.
#12	Justin commented on 22 Nov 2006 I don't like the negative attitude you seem to hold about Spring. Spring came along at a time when EJB was a complete and utter mess. Some really bright people realized that and created something lightweight and extensible. Spring XML and wiring beans is a joy in comparison, and really is a no brainer. In my book, Spring + Hibernate have already proven themselves. EJB3 better be pretty damn good to remove that oh so bitter taste that 1 and 2 left behind...
#11	Yi commented on 21 Nov 2006 I use hibernate and I'm not scared of sql. For CRUD apps, it can be tedious to use jdbc because you end up binding your java variables to the db fields 3 times (for insert, update and select) in the jdbc code, while with hibernate you just do it once. The difference can be quite significant if you have a lot of db columns.
#10	jeff davidson commented on 19 Nov 2006 delete from emp e where rowid > (select min(rowid) from emp e2 where e.id = e2.id);
#9	Agusti Pons commented on 17 Nov 2006 Very goog article. For years I've been developing my own framework to interact with backend systems (say databases). The work is public in http://www.microcalls.org It may be interesting to you. Thank you
#8	{Complexity} commented on 16 Nov 2006 Trackback Added: he Return To Java EE Standards!; He didn’t mention why EJB3.0 is better than other framework though, it’s quite meaningful in terms of unification. That’s true there are too many frameworks out there!! Spring + Hibernate EJB3, POJO + JDBC? — In the beginning there was ...
#7	Rob Bygrave commented on 16 Nov 2006 Great article but perhaps I don't 100% agree. - SQL Knowledge is important - Totally - JDBC Knowledge is important - Totally - Simplicity is important - Totally - Spring/Hibernate approximates EJB3 in complexity - Totally - We should just write JDBC - not so sure... For me I'd look to EJB3, JDBC and what is in the middle ground. 1. Is EJB3 more complex than it needs to be? 2. Is writing raw JDBC really a good option? 3. Is there middle ground? Is EJB3 more complex than it needs to be? ----------------------------------------- From my perspective EJB3 has inherited unnecessary complexity from Hibernate and Toplink. The EntityManager, attached/detached beans, merge, flush are all inherited concepts that are not actually necessary for ORM. Ebean offers EJB3 ORM features for about 800k and I think other frameworks will come that provide EJB3 features with a much simpler API. Refer: http://www.avaje.org/ejb3.html Is writing raw JDBC really a better option? ------------------------------------------- Don't get me wrong - in pretty much any real world app there may be a need for raw JDBC. With a different slant I would say that ORM is good, but that relational approaches are sometimes simpler and easier. For me this is the case for updates/deletes in a stateless environment and for Ad Hoc queries (I don't think ORM is well suited to these cases). However,once you start caching something you also need to understand how to invalidate the cache and how this works in a clustered environment. - Then you decide you want Statement Batching... - Then you decide to support Oracle, MySql and SQL Server and find the inserts work a little differently - Then you want to use LIMIT, or ROW_NUMBER to perform pagination on the database side - Then you decide you want event listening - Then you decide to integrate Lucene Text Searching... Now perhaps this doesn't happen but I would suggest that once you start down the road of writing JDBC for everything then maybe you end up with something that starts looking like a lightweight persistence framework? Is there middle ground? ----------------------- Obviously I am biased as I wrote Ebean exactly to fit into this middle ground for people who want EJB3 (or Spring/Hibernate) features but are put off by the complexity. More than that, there are some interesting omissions from the EJB3 API. http://www.avaje.org/ejb3api.html However I would expect other projects to be out there to do exactly the same thing. These simpler ORM products may be a better option for some.
#6	scott m gardner commented on 16 Nov 2006 Why use Spring, you ask? I use it so that I can develop and test my code independently, so that beans do not need to know the other beans and to reduce fragility. The minimal amount of XML required to wire beans together is a vast improvement and simplification of the reams interdependent code and factories required with out. The only part of Spring that could possibly be considered heavy weight is the database templating, and I don't use that. To consider the Spring core heavy weight might suggest that the lifter is a light-weight ;) The only reason not to use Hibernate when doing OO programing is that you are stuck using DB2400 and its broken JDBC implementation. Although Hibernate has a defininte learning curve and requires a skilled domain modeller to take full advantage of it, it is still one of the best ways to keep the business logic in the object model and insulate your project from the relation model.
#5	Alain Bergeron commented on 16 Nov 2006 If I may, hibernate and any pojo like ORM tools are great when you have a skilled OO team. Otherwise, you still end up mapping your jdbc result set to java object and by mean of reuse, you will end up creating your own little home made framework which the support team or other developers will have to learn instead of a well known frmework like hibernate. That said, I am currenly using ejb3 and so far looks very good either for a small team or a bigger team.
#4	BigBadJim commented on 16 Nov 2006 You nailed it! I'm forwarding this to all my fawning acolytes at work!
#3	Shamsher Dhaka commented on 16 Nov 2006 Hi, I truly ackn of what you said in this article. Keep the base and concept strong over which the frameworks are layed. regards, Shamsher
#2	Paul Sager commented on 16 Nov 2006 Many stars **** for you thoughts, confirming my deeper feelings about heavy weight frameworks. I am stuck in a medium-sized application, consisting simply of many small processes, which is permanently ensnared in an obsolete version of a major AppServer. Besides being a Java developer, as a Christian pastor, I take the Biblical allusion as a non-offensive creative rhetorical style, handled artistically; as I hope you intended it.
#1	Antonio W. Lagnda commented on 15 Nov 2006 Entertaining article. Spring + iBatis or Spring + Spring JdbcTemplate will give you SQL experience as well.