I have been investigating the best place to manage my DTOs and your example works for the case where one view or formbean collects all the data needed for a DTO. But for the case where you have multiple views to collect all the data needed for one or more DTOs that are needed by a business layer method. The business layer should not care about how you gathered the data for the DTOs (1 or n web pages), it just needs the DTOs. So I believe the view actions should manage the DTO creation and pass DTOs to the business layer. Opinions?
-----Original Message----- From: Robert Taylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 9:37 AM To: Struts Users Mailing List Subject: RE: the context Adolfo, 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 serivce.doSomething(view); } 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 "views". HTH, robert > -----Original Message----- > From: Adolfo Miguelez [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 17, 2002 8:35 AM > To: [EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >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: http://messenger.msn.com > > > > > >-- > >To unsubscribe, e-mail: > ><mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: > ><mailto:[EMAIL PROTECTED]> > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
