This is why Java has exceptions. In our case the backend mostly throws standard EJB exceptions (RemoveException, CreateException, etc), the business delegate translates those into our custom application exceptions, many of which are handled by our base action class, otherwise they bubble up to the specific action class and we generate the appropriate ActionErrors.
-- Voytek Jarnot Quidquid latine dictum sit, altum viditur. > -----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]
