I wants to learn hibernate.but i don't have knowledge of struts.Is it Necessary to learn struts before hibernate??
Thanks in advance..''
Swela Jathar wrote:I wants to learn hibernate.but i don't have knowledge of struts.Is it Necessary to learn struts before hibernate??
Simple answer: No.
Hibernate is an extension of the Java Persistence Architecture (JPA) framework, as has to do with getting/saving data to and from databases, whereas Struts is used for writing Web applications.
The two are often used together, however.
Harsha Smith wrote:Learn Spring and forget about struts.
Actually, I'd say: "Learn Hibernate and forget all those other alphabet soups".
Mind you, that could be because I'm a warty old DBA and hate all that new-fangled GUI and "Webby" stuff .
On a slightly more serious note though: All non-trivial applications are likely to need to save data (and Hibernate is a very good tool for doing it with Java); not all of them need a GUI (and certainly not a Web) interface. Cart before the Horse.
Furthermore, there are new additions to the "World of Web" almost monthly, and it's difficult to keep up. Hibernate has been around for a while now, and has the "Winston Ronseal seal of approval" (it does exactly what it says on the tin).
But, at the end of the day, your decision is much more likely to be determined most by 'what rocks your boat'.
Harsha Smith wrote:Learn Spring and forget about struts.
Not necessarily. I absolutely adore Spring. But to be honest, Struts 2 is also well worth a consideration.
Harsha Smith wrote:I thought it was Spring -> Hibernate
There are no direct dependencies between any Web MVC framework (Struts, Spring MVC etc.) and any Persistence framework (Hibernate, TopLink etc.). It's always good to know about stuff, but there is no particular sequence in which you need to learn these frameworks.
development in many ways. Spring offers solutions for almost everything . Spring plays well with other frameworks. There are many advantages of using Spring in your application.
I agree with Winston that almost everyone is using Hibernate in their applications. That makes Hibernate a must learn tool for Java Programmers.
If you see job postings, there aren't many takers for Struts 2.x professionals. Many employers now-a-days are seeking professionals with Spring and Hibernate expertise and they are being paid heavily
My point is no matter how much we like a framework or how much it's in demand, we should never close our mind towards competing frameworks. An easy example is Spring 2.x (MVC) vs. Struts 2.x, where the former relied upon a Controller hierarchy and command objects, whereas the latter brought the concept of having the model properties and actions both into a single class, which was well worth a consideration. Later, Spring brought @ based approach in 3.x, which I personally don't like a bit. So, three may be some aspects in all frameworks one may or may not like. Knowing about competing frameworks makes us understand what we are missing. Hence, I found "forget about Struts" a little too harsh.
As far as Hibernate is in question, learning any ORM gives you a nice, new way of approaching Java-SQL integration. However, it's not always the best choice for a project. For example, if your application is using a pre-existing database schema which you can't modify much, you may want to evaluate iBatis. If your application is relying upon a lot of logic in Stored Procs, you are actually better off without ORMs and should stick to plain JDBC, possibly with Spring template. Also, which using Hhibernate in a stateless environment like Spring MVC or Struts (unlike Seam), it's very easy to run into LazyInitializationExceptions all over the place. Again, it can be better handled with Spring WebFlow, but the question is how far would you go.
Bottom line is, I think the most important understanding one can have about all such frameworks is their strength and weakness and their applicability in a given situation. Right tool for the job makes it so much easier and fun.
As you know, it is not possible to learn and get hands on experience on all the frameworks(IBatis,Tapestry,Wicket, GWT, Struts, Flex, Spring, Hibernate etc). So considering what's more in demand in the job market and keeping the time limitation in mind, I suggested OP to go for Spring and Hibernate.
Core Java + Spring + Hibernate + J-Unit + Oracle Sql and PL/SQL ....The chances of getting a high paying job are really high. What do you think?
And annotation based approach in spring 3.x reduces the xml configuration greatly. As we know, applicationcontext.xml is a sensitive file and we don't want everyone to mess with it.
And about LazyInitializations, what if we change the fetchtype to eager or handle them using "left join fetch"?? I am not sure
off the topic:
More than 6 years of experience is awesome dude. From Hyderabad or Bangalore?
For example, Swing was virtually written off by its critics. I stil kept 'tabs' on it (pun intended) and it turned out to be pretty big in investment banks which are the highest payers in IT. Similarily, when Spring was picking up, EJB was pretty big... market keeps changing, but you need to find what you like.
I agree that it's probably a good idea to first learn what's in demand, but as I said before, one should always be well aware of alternatives as much as possible.
With the modern IDEs, I think the XML mismanagement can only be attributed to poor design of the application. I'm an old school programmer and I like a proper flow of execution and the ability to debug not just inside my application code, but also inside Spring/Struts or even Tomcat, right from the point a request is received till response is delivered. Annotations appear to be doing a lot of 'magic' and calls just get routed to application code, breaking the flow of end-to-end execution. That's why I didn't like it a lot when the Contoller hierarchy was deprecated in favor of @. I like to keep config completely out of code, so, in a way, I like XML config. Also I'm of the opinion that a tech lead should trust members of his team, and we have used XML config in a team of 50+ people, most of them quite junior. Trust me, it works. Just needs a bit of trust and a good amount of tech mentoring to keep everyone on the same page.
As for LazyInitializationException, it's not alays a good idea to always fetch the complete graph of all the related entities eagerly. More importantly, this decision should be taken from a design point of view, rather than a framework forcing us to do so.
I have been working with Java since year 2000 (did my SCJP back then in v1.2 it included AWT ) and with Spring/Hibernate for last 6 years. Mostly in Mumbai, and lately in London for last year and a half.