Related
I am fairly new to the programming world . I work with web applications in Java . I am learning struts2 / hibernate / spring .
I am thinking , instead of reading hibernate from the tutorials , it's good to read the complete source code . Basically I am planning to learn the complete framework code , to understand how caching is implemented , how transactions are handled , how multiple threads are handled etc.
Have anyone of you done this kind of thing before ? My intention is , if we know one particular framework in and out , then it will be very helpful for designing applications .
The best way is the simplest way: Build something! Start small, but treat it like an incremental, iterative exercise and add features that cover all the aspects of the framework you want to cover. Peruse as many books, blogs, and Stack Overflow entries as possible to learn more from people who've actually used the framework before and apply what you learn. It's the best way to learn a full stack framework!
You learn a framework and programming like you learn to do most anything else well: spend a lot of time on it. See this question and its answers and its duplicates. Keep reading, learning and experimenting. Start to build small projects. You're on the right track, keep at it.
Diving straight in framework code isn't a great starting point. Here is how you should progress:
Think of a project you'd like to work
on related to the framework i.e.
project idea
Failing to satisfy point
1, just follow the examples in the
official documentation and try to get
your hands wet with things
Help out
folks on the IRC/forums since this
would surely force you to dive
deeper than the normal stuff
Look
into bug reports and try to make
sense of things. Can you understand
the problem in consideration? If no,
you might want to look into the
"developers getting started guide"
for that project.
But, I'd just like to point out that though knowing a framework inside out from a code view point might be a nice thing, it certainly isn't a requirement to effectively use a framework. That's the entire point of using a framework (apart from reinventing the wheel that is :>).
For beginning understanding on how a framework solves your problem, you often need an example that is much less than the fully featured framework. Since all of your examples cover web presentation to differing degrees, I suggest "Bitter Java" by Bruce Tate. It does an excellent example of presenting a very poorly written web application, and then reworking it to improve it. It will give you a good understanding of the MV2 architecture, on which most modern frameworks are based.
The frameworks are merely the "improved versions" made reusable by asking you to provide your "plug-in content components".
I am php programmer but i am learning java now. i have finished the core java and build small projects using jdbc , mysql gui etc.
Now my boss wants to build the website where user will collect points and they can shop based upon points left.
But the initial phase will be only the logs/registration/admin area etc.
Now i have two options
1)Do in php
2)DO in java
I really want to do in java thats why i was learning it. Now now the project came early.
I wanted to learn spring , spring mvc , hibernate etc , design patterns but now i can't spend time first to learn.
i want to ask that what will be good solution to go at it. Initially was thinking of doing the website in JSP.Is that ok
O i am thinking of using Wicket and not using hibernate, is wicket enough to build ecommerce site. or i need anything else as well
I know only core java , what should i do
PHP development is very action/template-oriented, AFAIK. Wicket is a component-based framework, that heavily applies object-orientation concepts, and that may take some time to grasp. If you don't have much experience with OO, and your deadlines are tight, maybe you'll prefer an action-framework (Struts2, SpringMVC), which is far better than raw JSP. But, if you have some time to spend, and the will to learn, Wicket is definitely a great framework!
Spring is also nice, and while dependency injection is not something you see often in PHP, it's simple enough (Spring is well documented, its reference doc is actually useful, and you'll find many tutorials and examples on the Internet), and it's definitely worth learning.
Hibernate is a very good framework for persistence, but if all you know is plain SQL/JDBC, it takes some time to master it to the point that you don't get frustrated with mapping, and lazy-loading errors. Again, try it if you have some time to spare and the will to learn.
Wicket+Spring+Hibernate is a really nice combo, I use them a lot. It may or may not be the best stack for your case. As everything in IT, it depends on the context. But I think they are very sound technologies, individually or combined.
Consider Struts 2. It is both effective and there is a good size community here if you have any questions. I don't know wicket, but any web framework is better than straight JSP.
Hibernate is nice but since you have a lot on your plate you should probably stick with straight JDBC for now. Spring is also very nice, it is easy to integrate spring DI with struts2 (so easy as a matter of fact I would recommend you just start that way).
One of the fastest ways to get a Java webapp up and running is to use Play Framework.
I am working on medium sized web application 4-5 tabs, user login for about 100k users. We are completing redesigning the application from scratch and using spring and hibernate, connected to MySQL.
Did you experience major issues and what where did Spring benefit your application.
No major issues. Spring was particularly of benefit for:
Making all the configuration plumbing consistent and straightforward
Dependency Injection to support better factoring of code
Declarative "Open Session In View" functionality for Hibernate
Declarative Transaction Demarcation
The Acegi (now Spring Security) project made it easy to integrate a custom security model
The Spring data access support removes the need for a lot of boilerplate from any JDBC access - maybe not such a boost for Hibernate usage, but we had a mix of both. It also allows you to use JDBC & Hibernate together fairly seamlessly
In addition to what has been said so far, I would focus on newer style annotations for both Spring (e.g. #Controller) and Hibernate (e.g. #Entity). It will further reduce your codebase leaving you with less code to maintain. On the downside, there is a pretty significant learning curve, but ultimately the lesson I learn time and again is that the benefits of Spring + Hibernate far outweigh the (learning curve) costs. You simply have to write a lot less code letting you focus on the business.
+1 Spring+hibernate......
100k users is not mid-size....that is huge.
With spring, you can force coder to code to interfaces and this increase testability. This is the benefit i don't hear people talk a lot about.
take a look memcached to cached data memcached.....
techincally speaking I have, I've deployed commercial applications with numbers from the thousands to a few hundreds of thousands using spring, hibernate and both.
From the management perspective in one case, I had a team that were good technologists, so they managed to rewrite an app with spring and hibernate but... they went crazy with the interfaces (each new object to the model needed 16 interfaces), abused the AOP so transactions and logging were almost impossible to follow and stack traces were meaningless, used tools to map the hibernate files without fully understanding what was being done (in some cases joining 4 tables for what could've been a simple entity, and a variety of issues that made the resulting application much harder to enhance, debug, fix, even setup the developer's environment....)
my 2c
As Julien Chastang said, you need to factor in the learning curve in your estimations if this is your first project. We failed to do that on our first try and ended up having to adjust a lot of our planning because several aspects of Hibernate were "hard" (eg. took some time) to figure out.
One specific piece of advice I can give based on an issue we came across is: if you need to write complex SQL, and you don't want to spend the time figuring out how to get such queries working within HQL or other offerings within Hibernate, get it working first in vanilla SQL and then go back later and patch it back into Hibernate.
Obviously there are a million ways to build an application like this, both in the java frameworks world and with things like Rails or Django.
A big selling point for me is that both spring and hibernate have become defacto standards in the java world, so they definitely qualify as "things you ought to know" ( I get asked on every job interview). Spring more so than Hibernate.
Getting the value of spring took a few spring-enabled apps before it made sense for me. It enforces independant code modules and a certain style of component design that facilitates testing. I'd suggest you just go with it and get the sense of the value of it from use.
I have mixed feelings about Hibernate, though it's important to use some kind of db layer, so you may as well.
Also see this question.
There are some situations with Hibernate where creating a particular object to relational mapping, or writing a particular HQL query, is very difficult. However, you're going to run into 1 thing like that out of 10, and the more normalized your database the better off you will be. It's worth it.
Any new Java web project should use Spring MVC (2.5+ with Annotations) and Hibernate.
There is a large understanding overhead to hibernate and spring. I'd only suggest it if you have plenty of time or an experienced java/spring/hibernate developer to call on. With a spring project once you get it going you can basically ignore the spring parts of it and concentrate on page and logic design. Hibernate is not that difficult. HQL is a harder ask. Most of my time is spent at the bean and JSF level. Comparing that layer of my project to some mates who are messing about in JSP, I'm glad to be in the ease of JSF. I easily swapped to Oracle from the initial implementation in MySQL, so that proves that Hibernate handles abstraction nicely.
in addition to what has been said so far, i strongly suggest the book: Spring Recipes - Problem Solution Approach (Amazon), in combination with the very good online documentation you should be ready to conquer the world ;-)
I can't seem to find any recent talk on the choice. Back in '06 there was criticism on Hibernate Search as being incomplete and not being ready to compete with Compass, is it now? Has anyone used both and have some perspective on making the decision.
I am developing a web app in Java in my free time, its just me so I'm looking to cut corners everywhere possible while minimizing the effect on the end product. Having said that the searching capabilities of my project are priority one! I have spent a good deal of time making the database model to back the system. The ability to get the user what they're looking for is what will set my app apart. So, speed is expendable ...obviously to a reasonable degree.
Here are my current thoughts on the technologies for this app, and if you see any glaring newb mistakes be gentle ...I'm an expert at nothing.
DB: PostgreSQL
Platform: Java
Frameworks: Spring, Hibernate, Seam
Obviously, I've chosen all free (as in beer) technologies and ones that as far as I can tell play nice together. So what do you guys think, Compass or Hibernate Search to round things out?
-Nomad311
<Careful. Biased person here: I am the project lead of Hibernate Search and author of Hibernate Search in Action by Manning>
If you are targeting Hibernate as your persistence provider, I think you are better off using Hibernate Search as the integration is very smooth (configuration, entity discovery down the the same APIs and programamtic model).
If you want to index a lot of "stuffs" that are not in your database, then Compass is a better fit.
We are working on Hibernate Search 3.2 at the moment: our road map is here
Hibernate Search is a complete product, and it's based on Lucene, which is one of the fastest open source search engine out here.
As an example, some benchmarks:
http://developers.slashdot.org/story/09/07/06/131243/Open-Source-Search-Engine-Benchmarks
Plus, it's fully integrated with Seam and Hibernate (look at the example in the Seam dist).
I suggest you to be more specific about:
Hibernate Search as being incomplete
I'd like to know in which part it is incomplete.
Compass is no more as of elasticsearch is new one after compass. So I think better to use some stable one. (Possibly Hibernate Search)
My developers are waging a civil war. In one camp, they've embraced Hibernate and Spring. In the other camp, they've denounced frameworks - they're considering Hibernate though.
The question is: Are there any nasty surprises, weaknesses or pit-falls that newbie Hibernate-Spring converts are likely to stumble on?
PS: We've a DAO library that's not very sophisticated. I doubt that it has Hibernate's richness, but it's reaching some sort of maturity (i.e. it's not been changed in the last few projects it's included).
They've denounced frameworks?
That's nuts. If you don't use an off-the-shelf framework, then you create your own. It's still a framework.
I've used Hibernate a number of times in the past. Each time I've run into edge cases where determining the syntax devolved into a scavenger hunt through the documentation, Google, and old versions. It is a powerful tool but poorly documented (last I looked).
As for Spring, just about every job I've interviewed for or looked at in the past few years involved Spring, it's really become the de-facto standard for Java/web. Using it will help your developers be more marketable in the future, and it'll help you as you'll have a large pool of people who'll understand your application.
Writing your own framework is tempting, educational, and fun. Not so great on results.
Hibernate has quirks to be sure but that is because the problem it is trying to solve is complex. Every time someone complains about Hibernate I remind them of all of the boring DAO code that they would have to maintain if they weren't using it.
A few tips:
Hibernate is no substitute for a good database design. Hibernate schemas are OK but you will have to tweak them occasionally
Eventually you are going to have to understand how Hibernate lazy loads classes and how that affects things. Hibernate modifies the Java bytecode and you will need to delve into the depths sooner or later if only to explain why object links are null.
Use annotations if you can.
Take the time to learn the Hibernate performance tuning techniques, it will save you in the long run.
If you have a fairly complex database, Hibernate may not be for you. At work we have a fairly complex database with lots of data, and Hibernate doesn't really work for us. We've started using iBATIS instead. However, I know a lot of development shops who use Hibernate successfully - and it does do a lot of grunt work for you - so it's worth considering.
Spring is a good tool if you know how to use it properly.
I would say that frameworks are definitely a good thing - like others have pointed out, you don't want to reinvent the wheel. Spring contains a lot of modules which will mean you won't have to write so much code. Don't succumb to the "Not Invented Here" syndrome!
Lazy loading is the big gotcha in MVC applications that use Hibernate for their persistence framework. You load the object in the controller and pass it to the JSP view. Some or all of the members of the class are proxied and everything blows up because you Hibernate session was closed when the controller completed.
You will need to read the Open Session in View article to understand the problem and get a solution. If you are using Spring the this blog article describes the Spring solution to the open session in view issue.
This is one thing (I could remember) that I fell into when I was in my Hibernate days.
When you delete (several) child objects from a collection (in a parent entity) and then add new entities to the same collection in one transaction without flushing in the middle, Hibernate will do "insert" before "delete". If the child table has a unique constraint in one of its columns, and you are expecting that you would not violate it since you have already deleted some data before (just like I was), then get ready to be frustrated.
Hibernate forum suggests:
It was a DB design flaw, redesign;
flush (or commit if you will) in between the deletes and inserts;
I couldn't do both, and end up tweaking the Hibernate source and recompiling. It was only 1 line of code. But the effort to find that one line was equal to approximately 27 cups of coffee and 3 sleepless nights.
This is just one example of problems and quirks you might end up when using Hibernate with no real expert on your team (expert: someone with adequate knowledge about the philosophy and internal working of Hibernate). Your problem, solution, litre of coffee, and sleepless night count may vary. But you get the idea.
I haven't worked much with Java but I did work in large groups of Java developers. The impression I've got was that Spring is OK. But everybody was upset at Hibernate. Half the team if asked "If you could change one thing, what would you change?" and they'd say "Get rid of Hibernate.". When I started to learn Hibernate it struck me at amazingly complex, but I didn't learn enough (thankfully I've moved along) to know if the complexity was justified or not (maybe it was require to solve some complex problems).
The team got rid of Spring in favor of Guice, but that was more like a political change, at least from my point of view and other developers I've talked to.
I have always found Hibernate to be a bit complex and hard to learn. But as JPA (Java Persistence API) and EJB (Enterprise Java Beans) 3.0 has existed for a while things have gotten a lot easier, I much prefer annotating my classes to create mappings via JavaDoc or XML. Check out the support in Hibernate. The added bonus is that it is possible (but not effortless) to change the database framework later on if needed. I have used OpenJPA with great results.
Lately I have been using JCR (Java Content Repository) more and more. I love the way that my modules can share a single data storage and that I can let the structure and properties evolve. I find it a lot easier working with nodes and properties rather that mapping my objects to a database. A good implementation is Jackrabbit.
As for Spring, it has a lot of features I like, but the amount of XML needed to configure means I will never use it. Instead I utilize Guice and absolutely love it.
To roundup, I would show your doubting developers how Hibernate will make their life easier. As for Spring I would seriously check if Guice is a viable alternative and then try to show how Spring/Guice makes development better and easier.
I've done a lot of Spring/Hibernate development. Over time the way people used both in combination has changed a bit. The original HibernateTemplate approach has proved to be difficult to debug since it swallows and wraps otherwise useful exceptions; talk to the Hiberante API directly!
Please keep looking at the generated SQL (configure your development logging to show SQL). Having an abstraction layer to the database doesn't mean you don't have to think in SQL anymore; you won't get good performance if you otherwise.
Consider the project. I've choosen iBatis over Hibernate on several occasions where we had stringent performance requirements, complex legacy schemas or good DBa's capable of writing excellent SQL.
As for Hibernate: a very good tool for application which deals with a rapidly changing database schema, a large amount of tables, do lots of simple CRUD operations. Reports with complex queries involved are rather less well handled. But in these case I prefer mixing in JDBC or native queries. So, for a short answer: I do think time spent learning Hibernate is a good investment (they say it is compliant with EJB3.0 and JPA standards, also, but that didn't come into the equation when I evaluated it for my personal use).
As for Spring... see The Bile Blog :)
Remember: frameworks are not silver bullets, but you should not reinvent the wheel either.
I find it really helps to use well-known frameworks such as Hibernate because it fits your code into a specific mold, or a way of thinking. Meaning, since you're using Hibernate, you write code a certain way, and most if not all developers who know Hibernate will be able to follow your line of thinking quite easily.
There's a downside to this, of course. Before you become a hot shot Hibernate developer, you're going to find that you're trying to fit a square into a circular hole. You KNOW what you want to do, and how you were supposed to do it before Hibernate came into the picture, but finding the Hibernate way of doing it may take... quite a bit of time.
Still, for companies that frequently hire consultants (who need to understand a lot of source code in a short amount of time) or where the developers sign on and quit frequently, or where you just don't want to bet that your key developers will stay forever and never change jobs -- Hibernate and other standard frameworks are a pretty good idea I think.
/Ace
Spring and Hibernate are frameworks that are tricky to master. It may not be a good idea to use them in projects with tight deadlines while you're still trying to figure out the frameworks.
The benefits of the frameworks is basically to try to provide a platform to allow for consistent codes to be products. From experience, you'd be well advised to have developers experienced with the frameworks setting in place best practices.
Depending on the design of your application and/or database, there are also quirks that you'll need to circumvent to ensure that the frameworks do not hinder performance.
In my opinion, the biggest advantage of Spring is that it encourages and enables better development practices, in particular loose coupling, testing, and more interfaces. Hibernate without Spring can be really painful, but the two together are very useful.
Retrofitting an existing project to any framework is going to be painful, but the refactoring process often has serious benefits for long-term maintainability.
I have to agree with many posts on this one. I've used both, extensively, in a variety of settings. If I could undo a design decision it would be to have used Hibernate. We actually budgeted a release in one of our products to swap Hibernate for iBatis and Spring-JDBC for a best-of-all-worlds approach. I can have a new developer get up to speed using Spring-JDBC, Spring-MVC, Spring-Ioc, and iBatis faster than if I just tasked them with Hibernate.
Hibernate is just too complicated for this KISS developer. And heaven help you with hibernate if your DBA sees the generated SQL the database sees and sends you back with optimized versions.
The top answer mentions that Hibernate is poorly documented. I agree that the online reference manual could be more complete. However, a book written by Hibernate's authors, 'Java persistence with Hibernate' is a must-read for every Hibernate user and very complete.
#slim - I am with you again this morning.
It sounds like a classic case of Not Invented Here Syndrome. If they aren't keen on spring, they should consider other options rather than rolling their own framework (whether they acknowledge doing it or not). Guice comes to mind as an possibility. Also picocontainer. There are others out there, depending on what you need.
Spring and Hibernate definitely make life easier.
Getting started with them might be a little time-consuming at the beginning, but you'll certainly benefit from it later. Now the XML is being replaced by annotations, you don't need to type hundreds of lines of XML either.
You may want to consider AppFuse to reduce your learning-curve: generate an application, study and adapt it, and off you go.
Frameworks are not evil. even the Java SDK is a framework.
What they probably fight is framework proliferation. You shouldn't bring a framework to a project just for the kick of it, it should bring consistent value in a reasonable time. Every framework requires a learning curve, but should reward you with increased productivity and features later on.
If you struggle with code that is hard to debug because of inconsistent database usage, complicated cache mechanisms, or a myriad of other reasons. Hibernate will add great value.
apart from the learning curve (which took about 1 month of practical work for me) there weren't any pitfalls, provided you have someone around to explain the basics for you.