Lot of lightweight Frameworks !

[Reghu Ram Thanumalayan]

Hello guys,
I have been programming in Core Java and Swing for almost one year. I wanted to learn J2EE and i got EJB,completed first. Then i turned my attention to Servlets and JSP.
But right now i am overwhelmed with the number of Lightweight Frameworks in front of me. Struts, Spring, Hibernate, Tapestry, Velocity, ets ..the list goes on. As an Enterprise Solutions Programmer, is it necessary to know all these frameworks ?
Where does Spring fit in the space of all these frameworks ? Is there any sequential way of learning these frameworks.. i mean start learning one first, then another and so on..

Help me out guys !

[Matt Raible]

Originally posted by Reghu Ram T:

But right now i am overwhelmed with the number of Lightweight Frameworks in front of me. Struts, Spring, Hibernate, Tapestry, Velocity, ets ..the list goes on. As an Enterprise Solutions Programmer, is it necessary to know all these frameworks ?

No, it's definitely not necessary to know all these frameworks. I think it's more important to know that they exist and what each one does. Then if you run into a situation where you have a need for one of these framework's features - you'll have an excuse to dig in and start learning.

Where does Spring fit in the space of all these frameworks ? Is there any sequential way of learning these frameworks.. i mean start learning one first, then another and so on..

Spring basically simplifies J2EE so you can quit worrying about how your application is architected and how the layers interact - and get back to writing the features of the application.

Spring Live covers all of these technologies and shows how easy Spring makes it to work with them. You also might want to take a look at AppFuse - it allows you to use many of these technologies (including Spring) w/o needing to know much about them.

[Alexandru Popescu]

I think that knowing everything it exists out there is quite impossible. What is more near to reality is to know about their existance and what are the problems they are trying to solve. Than at the moment you are facing a new problem you will know what direction you should look.
[ October 27, 2004: Message edited by: Ali Pope ]

[Glenn Murray]

Originally posted by Ali Pope:
I think that knowing everything it exists out there is quite impossible. What is more near to reality is to know about their existance and what are the problems they are trying to solve. Than at the moment you are facing a new problem you will know what direction you should look.

The cliche response is to "pick the tool best suited for your project". If it's a throw-away project, then it's nice to play with a plethora of frameworks and rant about this and that. If you have reason to believe that your code will be used ten years from now. then there are some deeper issues here, most of which are addressed by using a standard as opposed to a standard wannabee. Sure, standards change and become outmoded, too, but at least your conscience will be clear.

"Daddy, what's Tapestry?"

"It's an album by Carole King, honey, and don't let anyone tell you differently."

Cheers,
Glenn

[Matt Raible]

Originally posted by Glenn Murray:

Sure, standards change and become outmoded, too, but at least your conscience will be clear.

"Daddy, what's Tapestry?"

"It's an album by Carole King, honey, and don't let anyone tell you differently."

Cheers,
Glenn

It's an interesting argument. But would you say the same thing about Struts? Many consider this a "standard" - when in reality it's just another open-source project. Personally, I feel that Apache-hosted web frameworks are probably just as good as a standard. ;-)

[Alexandru Popescu]

This is indeed a good point. But how do you solve the 10-years dillema when the budget required by an open-source frameworks solution is 3-4 times smaller than one according to some standard?


./pope

[Jeanne Boyarsky]

Originally posted by Ali Pope:
This is indeed a good point. But how do you solve the 10-years dillema when the budget required by an open-source frameworks solution is 3-4 times smaller than one according to some standard?

Part of it is that there is no standard. Maybe Struts or JSF will become one, but as of right now we aren't there.

A standard shouldn't be more expensive than another solution though. Especially not a mature standard. Partly because there would be more documentation, support and best-practices available for the standard.

[Alexandru Popescu]

Jeanne which is the result of comparing the budget for a J2EE (CMP based solution - standard, plenty of documentatio and support) over the same solution based on Avalon + Hibernate (for example)?

./pope

[somkiat puisungnoen]

I think,
if you use commercial J2EE application server such as WebLogic, WebSphere, They're more expensive but you don't take time to learn because all have much more document and service of each product.

and IF you use open source technologies, cost is reduced BUT you much take time/money for learn/study open source technollogies and some risks when some error happen.

[Jeanne Boyarsky]

Originally posted by Ali Pope:
Jeanne which is the result of comparing the budget for a J2EE (CMP based solution - standard, plenty of documentatio and support) over the same solution based on Avalon + Hibernate (for example)?

./pope

That depends if you know Avalon + Hibernate and if you can find people to do maintenance on the application that do. It also depends how many problems occur. (I do get your point though.)

[Alexandru Popescu]

The experience with that project was great. Both architects (and tech leaders - this includes me ) have "light" knowledge about Avalon and Hibernate, and more experience with pure J2EE solutions. We have started this new road because we felt (this a poetic form - in fact we did lots of analysis, including budget (hr included - as the team was build right before starting) we will have a powerfull solution. This prooved in time to be absolutely true: the system is still up and running (moreover still selling, without major improvements).
As I've said we have evaluated also the hr side: finding experienced enterprise developers was easier than finding somebody trained in Avalon and Hibernate, but the costs and learning curve did not compare. I agree that we have spent some nights for reading documentation (this should be read: digging into code to find out how to solve problems) and in that time we have found many problems (mainly in Avalon, but we fixed 'em ), but finally we have gained more than experience, we have gained a great solution.

./pope