Is it hard to convert a web app built with Jsp, Servlets & mySQL to one with Spring & Hibernate?

Question

I'm currently working on building a java web app. I've been looking to use Spring and Hibernate so I get some proper exposure to them, but I'm just getting burned out reading and learning about them. If I go ahead and build it with JSP and Servlets on a MySQL back end, what kind of levels of code reuse would I be looking at? I imagine the JSP's and POJO's would be more or less identical, but what about the rest of the code?

Thanks!

Answer 1

It depends on

• how much you have business logic mixed up with presentation logic
• if you use pojo's

If you have biz logic separated, and use mostly pojo's, then it's easier.

Then it depends on how much spring and hibernate you want to use.

• you can reuse the sql already written, or you can rely on hibernate to generate sql for you
• you can use spring managed beans
• you can use spring web mvc

For a generig aproach, you will want to reorganize your app in a layer oriented way:

• a repository layer that handles database calls
• a business layer, which holds business logic, data transformation, and has no dependencies; business layer calls the repository layer
• a web layer, where you have your controllers, presentation logic; web layer calls business layer code

Answer 2

Refactoring is always a hard job.... You should consider iterative section refactoring (modules/logical units).

Spring isn't invasive. So its use should be easy. Have a look at "don't repeat the dao" from IBM. They have best practices which help you with a clean implementation.

If you use spring, you should have a look at spring webmvc!

Answer 3

It's likely that you can reuse the JSPs, assuming that you use JSTL and not scriplet code. You'll add Spring tags.

Hibernate isn't 100% necessary. You can start with Spring JDBC and migrate to Hibernate only if you think it can help you. I'd call that a second step to take after you have the functionality working under Spring.

Spring's pretty good for working alongside other code. It need not be an all or none proposition.

Spring will have you create a service interface. You'll have a persistence layer. The web MVC will isolate all the view concerns. You'll use Spring's front controller servlet to route requests to controllers. The controllers will worry about validation and binding HTTP parameters to objects and passing them to the services to fulfill the request.

You don't talk about security. Spring security will be a bonus.

Answer 4

If you build using servlets, JDBC DAOs and JSPs, then it would be fairly straightforward to introduce Spring to the application at a later date:

• Replace the servlet code with Spring controllers. This would be doing Spring a bit of a dis-service, since they're capable of being so much more than just servlet replacements, but it's a start.
• In your JDBC DAOs, make use of Spring's JdbcDaoSupport and/or JdbcTemplate support classes. The bulk of your JDBC code would remain unchanged, you'd just be able to remove some of the plumbing and let Spring take the strain.
• If your app makes use of web page forms, you can use Spring's form taglib if you choose, although that would require re-engineering the controllers also. You can just leave the JSPs as they are, if you choose, completely unmodified.
• You can start using your Spring context to start auto-wiring your controllers and DAOs together, reducing manually-written wiring.

You can do any of these steps in any order, one step at a time. Spring is pretty good at being useful for as much as you want it to be, and then getting out of the way.

Hibernate's a different kettle of fish. It's big and complex, and a bit scary to begin with. I suggest getting settled in with Spring first, since Spring makes Hibernate a bit easier to handle.