Is it possible to use a web framework but not be dependant on that framework?

Question

Hello All,

I am investigating the use of web frameworks with my Java web-app. My basic requirements are pretty much easy maintainability, testability and no repetition.

I have explored writing my own MVC-type app using some sort of front controller pattern and JSP's for the views. The benefit of this is that I have complete control of all aspects of my web-app and if I design it properly it should not be hard to move it over to a more tested framework in the future if I so choose. However, the con is that I have to reinvent the wheel so to speak.

I hear good things about the currently available web frameworks. Some technologies that I have been looking at are Spring, Wicket, Struts, Guice, Hibernate and Tapestry.

I am a bit wary of Tapestry and Wicket. I dont know TOO much about them but they seem to deviate from the servlet->model jsp->view formula. I am not sure if I am comfortable with that. Although, I hear that Wicket is actually the best fit with Guice and is extremely testable.

Spring seems like it could be a nice fit, but I am very wary of frameworks which attempt to do everything. I would love to use spring-MVC, but can I swap in other components? Can I for example use Guice as my DI engine while using Spring-MVC as my framework?

I have briefly looked at Struts but it seems overly complex for my needs and again seems to be a complete package.

I've never used Hibernate, but it seems to be the standard for ORM and if it's anything like ActiveRecord (which I have only been exposed to a little bit) I am sure it fits my needs.

I also have never really used Guice but people really seem to like it, and I am a fan of DI in general even though I am not sure how it is used in an actual application.

Basically, I am only really confident with writing Servlets / JSP's. I am not opposed to learning alternate technologies but I am looking for advice as to which ones would REALLY benefit me.

If I can make an MVC app using Servlets and JSP's is it worth it to incorporate Spring? Or should I just use Servlets / JSP's and incorporate a DI engine like Guice?

I am pretty sure I would like to use Hibernate for ORM, but I hear it can be pretty complex. All I am really looking for is a way to map my POJO's to a database, so if there is something better/easier to use I am willing to look it up.

I am feeling lost and am looking for a bit of direction from people knowledgable in the area, any opinions on any of these issues would be hugely appreciated. Thanks!

Answer 1

"Spring seems like it could be a nice fit, but I am very wary of frameworks which attempt to do everything. I would love to use spring-MVC, but can I swap in other components? Can I for example use Guice as my DI engine while using Spring-MVC as my framework?"

Agreed Spring provides a lot of stuff, but it's totally modular. You can use DI with or without AOP and so forth. And yes you can use Spring MVC and Guice for DI together.

"I have briefly looked at Struts but it seems overly complex for my needs and again seems to be a complete package."

I have used Struts for quite some time now, but even when I started using it, I found it easy as a breeze. The controller might seem overwhelming at first, but you will have real fun when you get the hang of it. The best way would be taking a look at some real world examples using Struts.

"I've never used Hibernate, but it seems to be the standard for ORM and if it's anything like ActiveRecord (which I have only been exposed to a little bit) I am sure it fits my needs."

Oh then if you found Struts to tough, Hibernate is huge. It requires a big learning curve. It pays at the end, but if you know ActiveRecord, I will suggest you to stick to it before you get a good amount of knowledge of Hibernate.

"I am pretty sure I would like to use Hibernate for ORM, but I hear it can be pretty complex."

IMHO, very true...at least for beginners. (Anyone suggesting a change here?)

"If I can make an MVC app using Servlets and JSP's is it worth it to incorporate Spring?"

You mean without Struts or any other framework? How?

Seems like you are trying to take on too much too fast. Try considering one thing at a time. DI itself is a tricky thing to implement in real world. Oh yes conceptually it's great, but what I mean is you need to first get a hang of things one by one.

Answer 2

Very simply, if you are comfortable with JSPs and Servlets, then if you want to save some of the drudgery of web programming, I would look at Stripes or Struts 2.

I am very familiar with Stripes, and only am aware that Struts 2 is similar, so I will focus this entry on Stripes.

As an aside, Struts 1 is worthless. It offers no value (frankly).

Stripes has several features, but I will focus on only a few.

The primary value of Stripes, and if this were it's only feature it would still be very valuable, is its binding framework.

Binding is the process of converting the requests string values in to the actions values. Stripes does this amazingly well. Specifically, Stripes binding does very well on nested and indexed parameters, as well as type conversions. You can easily have a form field named "currentDate" and then have a "Date currentDate" in your Action, and Stripes will "do the right thing".

If you have a form field named "mainMap['bob'].listOfThings[3].customer.birthDate", Stripes will make the map, create the list, create the customer, convert the string to a date, populate the birthDate, put the customer in the 3 slot of the list, and put that list in the 'bob' spot of the map. (I do stuff like this all the time.)

The binding of requests to Action variables is just wonderful.

On top of that you get, if you use their form tags, you get nice behaviors when, for example, they put "Fred" in your date field. You easily get the form back, with Fred in the field, and a nice error message.

Finally, I really like their Resolutions as a result from their Actions. For example, a ForwardResolution to forward to a page, RedirectResolution to redirect to a page, StreamingResolution if you want to pump data down the socket, etc. It's a very elegant feature.

Stripes has all sorts of power and does all sorts of things, but those 3 pieces are what make it best for me, and what I use 99% of the time.

Simply, it really stays out of the way and readily handles the "plumbing" without completely obscuring the HTTP request nature of the system.

For someone who is content with JSP/Servlets, Stripes I think is an excellent step up as it adds good, solid value with very little cost (it's simple to set up) and without having to toss out everything you already know, since it works just great with JSPs and JSTL. Learn the simple mechanism it uses to map Actions to URLs, and how simple it is to map requests to your actions, and you'll be flying in no time.

Works great with Ajax and the like as well.

Answer 3

The question illustrates some confusion. I think the definitive answer is "no, it is not possible to use a web framework but not be dependent on it".

But your instinct is good. You want to maximize the general benefit a framework provides by helping to properly layer and modularize your code and minimize its invasiveness.

With that said, I think Spring is the winner on both counts.

If you follow the Spring idiom, the structure of your code will be better by the use of interfaces, layering, and aspects. Some of the attention they pay to design is bound to rub off on you. That's as helpful as the good plumbing code they provide.

Your code base does not have to be 100% Spring. I've seen Spring used in enhancements to legacy Java apps that weren't rewritten from front to back.

Struts tends to not be a good choice because it is JUST a web framework. It encourages you to put all your processing in Action subclasses, never to come out. Spring injects the idea of a service interface that decouples the web tier from the back end. It's easier to swap out web tiers and expose the service as SOAP, RMI, EJB, or remote HTTP call.

Hibernate is far more complex than Struts. If you choose Spring, use persistence interfaces and start with Spring JDBC. When you're ready for Hibernate, you can always write a new implementation and simply inject it into the place where your JDBC version used to be.