My approach is to have:
JSP <-> Struts Form/Action <-> Business Rules <-> Database
The busines rules are set up as singleton object on servlet
startup. I've subclassed the ActionServlet and overloaded
the datasource init method, there I set up the four business
rule classes and put them into application scope, on
creation the business classes get their datasource reference.
The objects I pass around are data beans that model the database
closely (similar to entity EJBs).
So for logon, I have a User() object where I set the
user_id and password from the logon form, then the action
class will call User user = UserManager.logon(User user)
which will either find the user and return a fully filled
user object or throw and exception (I might change that though).
UserManager has other methods for logoff, update and create. So the
action code doesn't need to send the dataconnection because
that ties the Action too closely to the data store (what happens
if the authentication changes to LDAP or unix password/username
or database password/username?).
It also means I can reuse the business rules for another project
that might not be struts based. (But whay would I do that ;-)
Michael McCallister wrote:
>
> What strategies or patterns do people use to manage persistence of business
> object data in a Struts application when there is no EJB layer and there is
> a desire to keep the business objects as independent of the web portion of
> the application as possible? Do you use the Struts DataSource and pass
> either it or a Connection as a parameter to bean methods that take
> responsibility for managing persistence? Do you follow the J2EE blueprint
> and create separate Data Access Objects to support persistence? Are you
> using an open-source framework to manage persistence? This seems like a
> common problem, but I haven't seen much talk about common solutions.
>
> Mike
