It's just me, but I don't like to do the transfering in the action. I pass the form to the business locator, ResourceTO is actually your ActionForm. Then you session bean creates a Transfer Object given the form.
Example: LoginAction -> BusinessDelegate.validateLogin(loginForm) BusinessDelegate -> create LoginSession(loginForm) LoginSession-> create TransferObject(loginForm) Suzette H. Daniel -----Original Message----- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 8:31 AM To: Struts Users Mailing List Subject: Re: model - controller interface So in this code snippet from the example Business Delegate class, public void addNewResource(ResourceTO vo) throws ResourceException { try { session.addResource(vo); } catch(RemoteException ex) { throw new ResourceException(...); } } the parameter ResourceTO vo is some sort of Transfer Object, but where did this get wrapped up? In the action presumably, which means this Transfer Object is instantiated there and populated from the form bean, correct? thanks Adam Suzette Daniel wrote: > In general you are correct, these patterns have been used to build the > platform to which we work on. > > With STRUTS the business delegate is a class that all you action will > call to do the actual business work. > > Example (pseudo code of the flow): > LoginAction calls BusinessDelegate.validateLogin() > DisplayContactInfomationAction call > BusinessDelegate.findContactInformation() > > So other than UI stuff your action is pretty empty. > > There is a sample implementation of each pattern, code samples always > help me to understand the use of these patterns, hope it helps you > too. > > Go to this link, click on an image and scroll all the way down (who > knows why the samples are always at the bottom). > http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html > > It seems that you understand the use of this pattern, so now identify > what isa delegate in your system and use this pattern in your code. > Hope this helps. > > Suzette H. Daniel > > -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2003 7:54 AM > To: Struts Users Mailing List > Subject: Re: model - controller interface > > > Thought about doing that but opted for EJB with container-managed > persistence at some future point (procrastination setting in ;) ) > > Suzette, on the J2EE patterns side, and taking into account that I am > an > EJB newby (well, more like an EJB unborn child), it seems that I need > the Business Delegate pattern at the moment to co-ordinate my JDBC > calls, which I can later adapt to link to a Session Facade. > > Am I right that the Business delegate is in the servlet container and > the Session Facade is in my EJB container? > > I don't find the language and syntax of these design docs that easy to > grasp, so maybe I'm missing something here. In the struts context, my > actions would interface with my Business Delegate, is that right? > > thanks > Adam > > Andrew Hill wrote: > >>Id suggest you take the time to learn how to use one of the various >>persistence frameworks out there: He says having yet to do this >>himself... ;-> >> >>OJB >>http://db.apache.org/ojb/ >> >>Torque >>http://db.apache.org/torque/ >> >>Hibernate >>http://hibernate.bluemars.net/?cowiki=35a3a22697b6c2f7504ce56c4b6b114c >> >>etc... >> >>If you want to try to roll your own (which could be a great learning >>experience) then the OJB site has links to quite a bit of helpful >>stuff, and of course a must-see site is: http://www.agiledata.org/ >> >>At the very least you would want to use a value object bean instead of >>individual parameters (which I garantee will be a maintenance >>nightmare) to pass the data to the update method. (nb: before you get >>tempted be aware that your ActionForm is a representation of ui state >>- not a value object!) >> >>-----Original Message----- >>From: Suzette Daniel [mailto:[EMAIL PROTECTED] >>Sent: Thursday, 24 July 2003 19:15 >>To: 'Struts Users Mailing List' >>Subject: RE: model - controller interface >> >> >>Try J2EE design patterns >>(http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html). >> >>Suzette H. Daniel >> >>-----Original Message----- >>From: Adam Hardy [mailto:[EMAIL PROTECTED] >>Sent: Thursday, July 24, 2003 7:12 AM >>To: Struts Users Mailing List >>Subject: model - controller interface >> >> >>I'm just about to write all the factory classes in tomcat (to connect >>via JDBC to the DB) for the updates and other CRUD my app will do. >> >>I am going to write methods for my actions to call, with a parameter >>for each item of data on the objects to be updated, e.g.: >> >>treeHuggerFactory.update(id, name, treeId, huggyId, expireDate, >>isHopeless); >> >>Then it occurred to me there might be a more intelligent OO design >>approach, especially since I want to change from using JDBC to EJB at >>some point. Should I be wrapping the object up in a bean and just >>passing the bean around, instead of listing all the properties? >> >>I'm thinking of the ease of maintenance in the future when things >>change as well. >> >>Anybody got any advice? >> >>Thanks >>Adam >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
