struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Taylor" <>
Subject RE: the context
Date Wed, 17 Jul 2002 13:37:22 GMT

I have been working on a model architecture for my current project and have
been using a similar concept. I'm not sure if everyone would agree its the
right way of going about things, but to me it seems to provide a clean
separation of responsibility. I have been heavily influenced by Chucks
Caveness book, especially Chapter 6 where he discusses the model layer.

I won't go into the whole architecture, but the following is how I handle
user input data in the various layers.

-Data is input by the user and the browser (HTTP protocol) handles getting
the raw data to the web server.

-The presentation framework (Struts) packages and validates the data using
some flavor of ActionForms.
 My XXXXActionForms implement a particular "view" interface which provides
the necessary getters and setters and
 importXXXX() and exportXXXX(), where XXXX is the name of the DTO (data
transport object). DTO are simple data
 structures which contain the types that are native to the business layer
(int, long, Date, etc...).
 The importXXXX() and exportXXXX() leverage the BeanUtils package to do the
conversions. All data members in
 the XXXXActionForms are Strings and therefore all input and output
parameters to the getters and setters on the
 "view" interface are Strings.

-Struts ActionServlet delegates the request to the XXXXAction class defined
by the action mapping.

-The XXXXAction class gets the appropriate "service" to handle the business
logic. My XXXXAction classes
 are simply proxies to my business layer. They delegate processing requests
to a "service". The "service"
 is just a business object that is very course grained where each operation
expects the appropriate "view" interface.

-The XXXXAction class casts the XXXXActionForm into the appropriate
interface and invokes the required operation on
 the "service" passing the "view" interface.

-The "service" invokes the appopriate exportXXXX() on the "view"
implementation which extracts the appropriate DTO.

-The "service" leverages other more fine grained business components which
carry out the appropriate logic passing
 around the DTO.

Notice that each layer handles the data in accordance with its particular
responsibility in the architecture.
 - The browser deals with data in the HTTP request
 - Struts deals with data as ActionForms
 - Services deal with data as "views"
 - The internal fine grained business logic deals with data as DTO

The business layer only knows about "views" and DTOs; it is ignorant of
anything in the web layer. There is no cross layer dependency
between objects which reduces coupling and increases the cohesion.

So I end up with something like the following in the XXXXAction class.

 public ActionForward execute(ActionMapping mapping,
                                 ActionForm form,
                                 HttpServletRequest request,
                                 HttpServletResponse response)
        throws Exception {

     MyView view = (MyView)form;
     MyService service = null;

     try {

          service = this.getMyService();

          // assume simple validation passed

     } catch (SomeException se) {

         // do something



and in MyService...

public void soSomething(MyView view) throws SomeException {

    SomeDTO sDTO = view.exportSomeDTO();
    AnotherDTO aDTO = view.exportAnotherDTO();

    // perform complex validation

    // execute business logic or throw some exception


This keeps all my logic for a set of common business requirements
encapsulated in a "service"
which can be used with any presentation framework because my "service" just
knows about the



> -----Original Message-----
> From: Adolfo Miguelez []
> Sent: Wednesday, July 17, 2002 8:35 AM
> To:
> Subject: Re: the context
> Following up with my own thread, I have thought that such a
> context could be
> useful for storing the info of the data in their native format,
> Date, ints,
> floats, .... leaving the ActionForms to hold data in String format, ready
> for the presentation layer.
> In some thread time ago (3/4 months), I remember someone suggesting to
> duplicate the info of the input data in the ActionForm, one for
> the Strings
> format and another one for the native format, and maybe making
> the casting
> in the validate() method.
> e.g. for each input parameter, 2 methods:
> public Date getDate();
> public String getDate();
> and their setDate() versions.
> In such a way, Actions could get the data already casted from
> String to its
> native java object from the ActionForm.
> What do you think about extracting such a duplicated info from the
> ActionForm to this "context"? Any opinions please?
> >From: "Adolfo Miguelez" <>
> >Reply-To: "Struts Users Mailing List" <>
> >To:
> >Subject: the context
> >Date: Tue, 16 Jul 2002 13:31:32 +0000
> >
> >Hi All,
> >
> >we are are developing a framework based on Struts, and adapting
> Struts to a
> >propietary middleware which, in turns, as usually, deals with
> the backends.
> >Struts would make up the presentation layer, more or less, delegating in
> >other layers for the business stuff.
> >
> >It has been suggested a patter model, which I did not know before, and,
> >approximately, it is based in a XML which holds all the
> application data in
> >a tree structure grouped by functional roles. In that way, the
> data is not
> >spread all around the app, but it is wrapped in this functional
> >abstraction. It could be seen as a central structure for holding all the
> >model (and i.e. the state) of the app. It is termed THE CONTEXT!!!!
> >
> >Actions fills the context, and send it to the middleware, which,
> in turns,
> >sends it to business layer. It has empty fields for the data
> that has not
> >been obtained yet (actually all the app data is wrapped inside the
> >context). Business layer fills the new data into the context,
> and the whole
> >context is sent back to the action which, in turns, extract the
> output data
> >from it to fill the value objects and send this to the JSP for rendering.
> >
> >Well, we are having actually, quite a lot of problems in
> integrating  this
> >new element with Struts, with the ActionForms, with the validator.....
> >
> >It is actually as a huge value object holding all the data of the app,
> >travelling forwards and backwards along the app layers.
> >
> >My questions are:
> >- has any of you seen a similar pattern? Any pointer is welcome.
> I do not
> >identify anything in the GoF patterns, but maybe I am not
> realising of some
> >of them.
> >- what is your opinion about it?
> >- could Struts, in future releases, include a context for
> wrapping the data
> >model for the app?
> >
> >Thanks in advance and sorry for the philosophical question,
> >
> >Adolfo
> >
> >_________________________________________________________________
> >Chat with friends online, try MSN Messenger:
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><>
> >For additional commands, e-mail:
> ><>
> _________________________________________________________________
> Join the worldÂ’s largest e-mail service with MSN Hotmail.
> --
> To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message