Hi, What i have been doing is the following, I wrote a simple class , which will hold all the errors in the business class (An ArrayList whoes each row is an error or message ) , and then send back this class to the Action class, and then in the Action class i have written logic to build ActionErrors , if there are any. So the call to my business class looks some thing like this ProcessError error = myBusinessClass.doIt(); where processerror is the place for holdin all messages The advantage i got buy doing this, is that i was able to pass on errors as well information messages to Action class which will forward them to the view
Ashish --- John Espey <[EMAIL PROTECTED]> wrote: > I would have the business components handle their > own DB connections (they > shouldn't rely on the presentation layer for that). > As far as your errors > coming back to the presentation layer, I usually > have a BusinessDelegate > class that the action makes business calls into. > That business delegate is > responsible for catching exceptions like SQL, > Remote, IO, etc. and then > wrapping them into more application/business > specific exceptions. Here is a > good description of the BD pattern: > http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.ht > ml > > > > -----Original Message----- > From: mech [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 03, 2003 12:05 PM > To: [EMAIL PROTECTED] > Subject: Design question: Model component using > Business logic beans > > > Hi, > > currently I'm doing all my business logic in my > Action classes. So > besides the execute() method I might have some > helper methods like > populateFormBean() or I even put those stuff in the > execute() directly > if it wasn't to much. > I have to do quite a lot of database queries to > populate the form bean > for the views. > > So actually the Action class should only do the > controlling. So far so > good and since things got to much in my Action > classes I planned to move > the code out into business logic beans to be > accessed within execute() > in order to do all the populate form stuff there. > > It's no problem to use a setter method to give my > business logic beans > the reference to my struts connection pool. Also > fine to do it with the > form bean. > > One thing, I'm having a bit trouble with migration > is the ActionError > stuff. > > Since most of the errors, like lost DB connections > or the rollbacks of > db transactions usually happen in my business logic > beans then, I wonder > what could be a good practice to pass those errors > back to the Action > execute() as I need those information in > <html:errors/> in my views. > > I guess if I import > "org.apache.struts.action.ActionError" in my > business logic, I'm doing a bad job to untie > business logic from my > controller, right? > I guess it would be similar bad like including the > servlet packages as > mentioned as a warning in the Struts documentation. > > > But on the other hand, it's quite useful to say > > errors.add(ActionErrors.GLOBAL_ERROR, new > ActionError("error.something.happend")); > > in my business logic bean in order to log an error > at the place where it > occurs, right? > > But to use a setter method in my business logic bean > writting all those > errors and retrieving them with a getter method in > the calling execute() > requires importing Struts packages... > > > Does anyone have good ideas how to untie business > logic from all > web-related stuff while still being able to pass > errors in a > sophisticated way back to the caller, like it can be > done with the > ActionError classes. > > I would appreciate any design hints from everybody > who doesn't put all > his business logic code into the Action classes or > it's execute() > method, since most books "speak about not to tie > business logic with the > controller", but usually do the opposite in the > sample code. ;-) > > Thanks > Michael > > > --------------------------------------------------------------------- > 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] > ===== A$HI$H __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
