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]
