Here's a concrete example of why it's not a good idea... I had a Struts-based application that I was recently asked to expose (some functions of) as Web Services. Well, this started me down my whole Struts Web Service Enablment Project route, but the point is that because it had to be quick, quick, quick (development time-wise), the easiest thing I figured was to expose the ActionForms, essentially, as the response to the service request, and just modify the RequestProcessor to deal with the input.
None of this is really too important except when it came to one of the services I wanted to expose, it looked at session data quite a bit. But, in a Web Service request, there necasserily isn't session. Now, all the code had been written to delegate out of Actions fairly well, but it was passing session along in many cases, one of them being this particular service I needed to expose. Now, what I wound up having to do was construct a session object on-the-fly and pass that in. Not a huge problem, but had the delegates not been coded to need session at all, this would have been a lot easier and quicker. In that instance, not passing session around would have been much better, and thse are the types of cases you'll want to convince your people are what they should be thinking about. This exact situation may never come up for you, but why not be prepared when someone needs a modification needed that all of a sudden isn't inherently web-based (as a Web Service can be)? -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, October 20, 2004 1:58 pm, Craig McClanahan said: > What he (Matt) said. > > If you are going to tie your Business Delegate class to web tier APIs, > there is not really much point in having them at all -- you could just > do your business logic in the Action.execute() method directly and > save having to maintain two classes. (That's a sub-optimal idea as > well, but if you're going to follow this path you might as well do > less work.) > > Craig McClanahan > > > On Wed, 20 Oct 2004 13:36:36 -0400, Matt Hughes <[EMAIL PROTECTED]> wrote: >> It's a bad idea because what if in the future you want to use that >> business logic elsewhere? What if you want to use it in a webservice or >> in a GUI standalone application. The business logic should have to know >> nothing about web servers and HttpSession objects, unless your business >> is building web servers. >> >> >> >> meena r wrote: >> >> >Hi, >> > >> >We have been mulling over an issue where , we have >> >people on our team who are proposing to pass the >> >HttpSession which we have in our Action classes to the >> >buisness delegate(which is an ordinary java class >> >which encapusulates calls the session facade). While >> >the j2ee blueprint for the business delegate pattern >> >says that the delegate decouples client code from >> >buisness component usage and lookup, folks in the team >> >am working on believe that there is no strong reason >> >why the session should not be made available to the >> >delegate. Please pour forth any opinion as to whether >> >this is a wise thing to or not. >> > >> >Thanks >> >Meena >> > >> > >> > >> > >> > >> >__________________________________ >> >Do you Yahoo!? >> >Yahoo! Mail Address AutoComplete - You start. We finish. >> >http://promotions.yahoo.com/new_mail >> > >> >--------------------------------------------------------------------- >> >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]
