|
Lofi Dewanto in his blog asks if Spring framework used with Hibernate is still a lightweight or a heavyweight champion of Java frameworks?
I believe that not only this combo, but even each of them separately is pretty heavy as ANY framework. Only reusable loosely coupled components are lightweights.
Spring framework is advertised as a set of components that can be used separately, but you can also wire them together by adding two pounds of XML. The minute you do this, you fall into an XML trap. So if you use any single component of the Spring framework it's lightweight. But as soon as it takes two to tango, and you are pulling a tiny roll of thin wire out of your pocket, it becomes heavyweight. Because wires (a.k.a. XML) tend to twist and create a mess.
Speaking of Hibernate, I'm not even sure WHY so many people are using it in the first place? I can understand if an enterprise architect is laying out a new design of a stack of business applications and wants to enforce to a firm-wide standard for data persistence. But if you are developing a typical CRUD application, especially when it comes to using already existing and not perfectly designed database, why even bother with Hibernate? Do you really hate or afraid of SQL?
Anyway, take an application built on the Spring framework components interconnected with thin wires, put on top of it Hibernate with the wires of different diameter, and maintainability of your application decreases while hard to find bugs are making themselves at home in your application.
During the last three to four years many people like bashing EJBs as an unnecessary complicated framework with lots of convoluted XML descriptors. Now EJB 3.0 with its annotations is trying to appeal to enterprise developers again. This won't be easy, because bad memories last for years. But do not kid youself when you substitute EJB for Spring/Hibernate combo. Your life won't be easier at all.
I do believe in standalone POJOs which know nothing about environment they are in (an IoC concept works fine), and know how to perform a specific function, i.e. send a message, manage transactions, create a pretty report based on provided SQL, model some financial process, find an optimal route, e.t.c. Just pass the required parameters to this black box, get the result back and do whatever you want with it. Stop wiring, just write the freaking code specific to your business application and forget about it when the new project start. Do not forget though about independent reusable components.
Spring is probably one of the best Java frameworks available today. It has only one drawback: it's a framework.
Because wires (a.k.a. XML) tend to twist and create a mess.
Is it really? Every application has to deal with wiring dependencies
between components for them to work together, and the use of XML in Spring
is where much of this functionality is implemented. Besides, wiring
components in Spring can take place over several XML files so modularity
with respect to seperation of concerns can be achieved through the use of
XML. For me, managing these XML files in Intellij is just fine; locating
them is two key-strokes away CTRL-SHIFT-N and CTRL-B. Its comfortable to
know that, as a developer, I have one place to look for the wiring instead
of crawling through actual code (which may not look pretty) to find it.
Lets just say I could untangle the mess much quicker through use of XML.
Since you run high-volume database-driven application, intimae knowledge of
SQL helps tremendously. Add to it a standalone reusable cache component,
and your application will rock. Is it worth using Hibernate jsut because it
has a cacheing component?
@heavyweight: I agree that Spring & Hibernate are heavyweight, but based on
your definition of lightweight, the applications that I write in the
aforementioned frameworks are lightweight :)
@sql. Anyu decent enterprise programmer must know SQL. Period. Yes, tediuos
JDBC programming has to be automated, and we do this not for Java though,
but for Adobe Flex. We use Java, metadata and XSL to automatically
generate all JDBC code required to populate a datagrid (if interested read
this article: http://www.adobe.com/devnet/flex/articles/daoflex.html ). I'm
not sure if there is a need, but we can easily modify this software to
generate Swing JTable from an SQL statemnent.
@sql--SQL is not rocket science here, lets agree on that. Any decent
programmer can pick up the basics in an hour or less. For me it was the
case. I do agree with you that every developer should have a solid
understanding of SQL but that doesn't mean we should /always/ use JDBC.
JDBC is error-prone, and it shouldn't be the choice of framework for
performance. Optimizaitons can offen be applied at the database level
rather than at the application level to reap a lot of gains. So how does
JDBC help me to become more productive?
@sql - At one of my recent presentations to Java developers, I've asked the
question, "Who knows how to delete duplicates from a database table?". NO
ONE KNEW. Do you know? When I asked the same qst on one of the online
forums, some Java developer proudly announced that with Hibernate you do
not create duplicates in the first place". Thank you very much! How about
some real world experience? What if the database table with dirty data
already exists and dirty feeds keep coming in nightly? Do not kid yourself.
Learn SQL.
@sql--I just witnessed a "Alex Trebek" phenomenon. Just because you asked
a question in which you know the answer for (most of the time related to
your own personal experiences), doesn't mean everyone should expect to know
the answer. I could easily come up with a related SQL/database question in
which you could not provide a 'correct' answer, does that mean you are
incompetent? No. Reminds me the time when an interviewer asks me would
Test.java -> "class Test { public static void main() {} }" would compile
(notice the missing String[] args). I didn't really care. If you know,
then great, but I hope you see the point I'm trying to demonstrate.
First, I would start with thanks to Yakov Fain on his excellent writing.
Between Hung Tang and Fain discussion I was enjoying the topic both that
both of you brought here. I read a lot articles about Mr. Fain and his
dimension of knowledge is more than normal dimension (which is
3-dimension). On the above discussion, I would go both of you partially. In
Mr. Fain articles and books, the things you noticed he evaluate new things
about JAVA, excellent. But, the thing that I missed is things are changed
now in this Google and Open Source movement. Companies are participating in
the Open Source and everyone how is planning for Open Source Business Model
knew that Open Source is a medium of collaboration. I'm not trying to teach
you on Open Source who knew better than you about JAVA and Open Source. But
if this is true then Mr. Tang is correct on his words we should think more
on business and think less (not saying avoid it) on core depth
architecture.
By bringing in a new framework, you create a need for new experts which
translates to better consulting rates. I think that the proponents of XYZ
framework have a monetary reason to push their respective frameworks
irrespective of wether the framework is the best suited for the job. First
it was struts, then hibernate/spring, and when there are too many
programmers versed in hibernate/spring someone will start the ball rolling
on the next best thing.
Well, I do not think someone starts develoment of a new framework just to
increase his rate. There is a long way before a framework is created and
someone start using it (and paying high rates). In terms of making noise, I
am very impressed by the Ruby on Rails guys. They make A LOT of noise and
they are making money now...While the RoR may be over-rated, a small number
of companies that decided to use it can provide a decent cash flow to a
small number of people who are experts in it. But again, I do not think
that David H. has created RoR just to build a new market for himself. First
it happened, and then he's winning the mindshare of Java developers in a
smart way.