struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Vickery" <j...@vickeryj.com>
Subject Re: moving on to Hibernate with S2...
Date Sat, 12 May 2007 15:31:02 GMT
If you like RoR (and I do) you might like some of the "magic" that
Struts 2 and Spring can provide.  It isn't quite perfect yet (at least
not the Struts 2 part), but I'm pretty happy with it.  By "magic" I
mean convention based configuration, which cuts down on the number of
places you have to enter the same data.

With a default Struts 2 + Spring IOC setup, adding a new Action means :

1.  Create an Action class
2.  Create a view file (JSP in my case)
3.  Describe the Action class and view in the struts configuration
file (struts.xml)
4.  Describe the Action class in the Spring IOC configuration file
(applicationContext.xml)
5.  "Wire" the dependencies needed by the Action class in the Spring
IOC configuration file (applicationContext.xml)

This seems like a lot of work, especially compared with RoR.  My
solution has been to use the following pieces of "Magic":

1.  Struts 2 "Zero-Configuration"
2.  Spring IOC "autowire by-name"
3.  Struts 2 Spring Integration

This cuts the above steps down to:
1.  Create the Action class.
2.  Create the View file
3.  Annotate the Action class.
4.  Add IOC properties to the action class

This only saves 1 step, but it cuts the number of configuration files
edited from two to zero.  In fact, the only files that need to be
edited are your Action and your View, which is just what RoR requires.

The downside, is the mess of Annotations that this approach requires
on the Action class.   There is also a "codebehind" plugin for Struts
2 that I have yet to try out, but might cut down on the required
Annotations.

The missing piece here is the Model component.  Hibernate offers one
solution, and by using Annotations instead of mapping files, you can
get close to the simplicity of Active Record, though not in terms of
setup.  My preferred solution, as of late, is to implement a Data
Access Layer.   This is more complicated, and more work to setup and
maintain than Active Record, and certainly requires more typing than
Hibernate alone.  However, I find that more often than not, the
database can prove to be a performance sticking point.  By having a
clear DAO layer I can tweak resource hogging auto-generated queries
without having to touch domain logic, which is what I found myself
doing when relying on Hibernate alone.

For example, if I have a survey building tool with an administrative
front end, and I have an Action defined to assign questions for a new
survey, the action might receive a surveyId and a list of questionIds.
 With Hibernate alone, I would be tempted to write something like the
following in my Action class:

Survey selectedSurvey = new Survey(surveyId);
hibernateSession.load(selectedSurvey);
selectedSurvey.setQuestions(null);
for (long questionId : questionIds) {
   Question q = new Question(questionId);
   hibernateSession.load(q);
  selectedSurvey.addQuestion(q);
}
hibernateSession.update(selectedSurvey);

Now, that's a terrible example of database usage, but it sure was easy
to write, and its rather readable, even with no comments.

Now, with a DAO layer defined, I might write something like this in my
Action class:

surveyDAO.setAssignedQuestions(surveyId, questionIds);

In the definition of the surveyDAO, I might use the same code that I
previously put in my Action class, and it might never prove to be a
problem even with all the excessive database.  However, if it did
prove to be a problem, I would know exactly where to address it, and I
could be assured that my database performance tuning would be
restricted to its own layer, and would not make my action any less
readable.

Josh



On 5/11/07, Ray Clough <ray@allthisisthat.com> wrote:
>
> Personally, I do *NOT* like to use Spring, because every time I touch it
> everything breaks.  I think that a better solution is to use a
> ServiceLocator to provide the Hibernate SessionFactory.  I did this in S1,
> and it worked very easily, and didn't break anything.  ServiceLocator is
> described in the "Core J2EE Patterns" book very nicely (available on-line at
> Sun).  In my opinion the rush to IOC and DependencyInjection is more of a
> fad/hype than a real benefit.  ServiceLocator is easier, and makes your app
> more portable, because you don't have to implement the IOC service before
> you can get your code to work in the new framework.
>
> All this, of course, is IMHO, and I know I'm probably a minority here.
> - Ray Clough
>
>
>
> Rick Schumeyer wrote:
> >
> > Now I'm trying to configure Hibernate with S2, which many others have
> > done.  I was trying to follow the example in WebWork in Action, but
> > things have obviously changed since then.
> >
> > To be clear, the problem is to create a SessionFactory once in such a
> > way that all my actions can easily have access to it.  The approach in
> > WWiA uses IoC.  As far as I know, it would work in S2 but would need
> > many modifications because package names have changed.  And perhaps
> > other mods would be needed?
> >
> > I'm not sure if the best approach is:
> >
> > a) Use the strategy in WWiA, but change the import statements to match
> > the current jars (and perhaps make other changes to match S2)
> >
> > or
> >
> > b) Something else.
> >
> > Perhaps someone could point me to a complete solution?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/moving-on-to-Hibernate-with-S2...-tf3729349.html#a10441853
> Sent from the Struts - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message