How easy would it be to refactor a small JSP/Servlet/JDBC project to SpringMVC/Hibernate

Question

With reference to this post, I am considering starting a new web-based Java project. Since I don't know Spring/Hibernate I was concerned if it's a bad plan to start learning them while creating a new project, especially since it will slow down the early development.

One idea I had was to write a prototype using tech I do know, namely JSP/Servlets/JDBC, since I can get this running much quicker with my current knowledge. I could then throw the whole thing away and start over with Spring, etc, but I'd like to consider how easy it would be to refactor a smallish project from JSP/Servlets/JDB to SpringMVC/Hibernate? My DB could of course be re-used but what about other code... would I expect to save most of it plugged into an MVC framework, or is the paradigm shift big enough this would cause more trouble than it avoids?

---

Please use the other question for more general advice on choosing technologies

Answer 1

I would advice either not using Spring/Hibernate, or using it right away.

Hibernate, but also Spring, influence the modelling of the data and the flow quite a bit. Porting an application from JSP/JDBC to Spring/Hibernate might not always be that easy, especially if you start taking transaction boundaries into account.

My personal advice would be to get a decent Hibernate + Spring book, and start from there.

Answer 2

If you follow good programming practices it will be easy to do the conversion. A servlet could become a controller and a jsp could be re-used as is to become a view. Of course if you are doing things like having business logic in your JSPs it will be more difficult to do the conversion. It will be also good if you already have a data abstraction layer.

This will be an interesting experiment and will help you understand better the advantages of Hibernate and Spring. You may find out that many things these technologies offer, you are doing them already by yourself the hard way.

Answer 3

I would advise that you start with Spring and use its JDBC templates and leave Hibernate out of it until you have it working.

Spring will encourage you to use interfaces, which means you'll separate the implementation from the method signatures. You can get everything up and running with Spring and swap out the JDBC DAO for its Hibernate equivalent once you're ready for it.

I can only handle one thing that I'm ignorant of at a time. If you're like that too, follow my advice and start with Spring alone.

Answer 4

+1 to @duffymo's advice. Hibernate is really a whole other beast, and it is especially difficult for folks who are so used to code straight-up SQL to switch to an ORM tool. I mean it took me awhile to be comfortable with Hibernate to do all the work for me, because I just didn't trust it will do a better job than my 'awesome' SQL code. But, as time passes by, I learn to accept that Hibernate is doing a fine job PROVIDED you configured it properly. :)

So, @john, I'll start with JSP + Servlet + Spring first, just like what @duffymo mentioned. Convert your DAO classes to use Spring's JbcTemplate. This forces you to create interfaces for your existing DAO classes. Make sure your DAO classes are stateless, I mean, it should be though. With that, you can easily test the crap out of it in your testcases.

For your servlet to utilize these DAOs, you need to do something like this...

ApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(servletContext);
SomeDao dao = (SomeDao) ctx.getBean("someDao");
dao.doStuff(..);

The reason for that "tad ugly" code to get the DAO is because Spring cannot wire up the DAO directly into your servlet because Spring doesn't manage your servlet at this point.

Once you get all of this working, you should have some understanding on how Spring's IoC works. Now, you can swap out your servlet and replace it with Spring MVC. I suggest you use Spring MVC 3.x so that you can build your web part the restful way. Trust me, it's whole lot easier and cleaner than Spring MVC 2.x, in my honest opinion.

Okay, when you have JSP + Spring MVC + Spring + JdbcTemplate working, I think it will be a good time to swap your database module from JdbcTemplate to Hibernate. Since you code by interface, it will not cause ripple effects to other modules. PLUS, you can reuse the exact same testcases to test the crap out of your Hibernate DAO classes. Sweeet. :)

... and that's how you end up with JSP + Spring MVC + Spring + Hibernate. :)

Breaking this whole thing down into smaller chunk makes it whole lot easier to learn and digest. At least, when things start breaking in development, you won't indirectly improve your swearing vocabulary, trying to figure out the problems.