[prev in list] [next in list] [prev in thread] [next in thread] 

List:       struts-user
Subject:    Business Logic for Dummies (was Iterating a ResultSet)
From:       "Ted Husted" <news.ted () husted ! com>
Date:       2000-12-31 17:07:30
[Download RAW message or body]

So, the architechture I'm now considering runs like this. 

(This actually may be an obvious approach to better minds than mine,
but as the subject says, this message is about Business Logic for
Dummies ;-)

Define a generic JavaBean for each logical field-set exposed by a (JSP)
view. 

Represent multiple field-sets (rows) as an array of beans.

Represent the business logic as an interface (or API) that can be
implemented by a subclass of ActionServlet. (Mostly to appease my sense
of order, but also to leave the AWT door open.)

Using the Example application as a sample domain, something like, 

public User getUser(String userName) {}  // UserName must be unique
public User[] findUsers(String namePrefix) {} // Users that match the
beginning of namePrefix
public Subscription findHost(User user String hostName) {} // One host
per subscription
public Subscription[] isAutoConnect(User user) {} // Zero or more
subscriptions can have AutoConnect set for a user
public User[] findHostUsers(String hostName) {} // Admin query to see
whose subscribing to a host

As implemented by the ActionServlet subclass, my application's
interface then executes the JDBC calls as needed (e.g. via the
datasource pool), and returns a bean, or an array of beans, to the
Action handler. 

The Action handler passes the bean, or beans, to the JSP view (e.g. in
a form bean). 

The JSP view displays the bean and/or iterates over the array of beans.


When receiving input from a JSP, the Action object would be responsible
for any validation before calling a method of  my application's
business logic interface. (Which in turn would pass the parameters to
JDBC.)

So, the Action objects become adaptors and validators to my
application's core interface, which handles the nuts and bolts, and
just returns beans or native types. 

If I wanted to use a non-JDBC database, I could implement another
ActionServlet subclass, using the same interface. The Action handlers
would still call the same methods, and the views would expose the same
beans. I would also have a serious head-start on porting the business
logic to AWT or another framework, should that come up.

I don't fully understand Enterprise JavaBeans yet, but I'm hoping that
this approach would be compatible. 

Any comments? Too much overhead? Am I a dummy? (which is possible,
since early exposure to Cold Fusion and PHP may have stunted my
growth;-)

One thing I'm wondering if I might later be able to somehow cache J2EE
RowSets, as a perfomance optimization. (Perhaps encapsulated in the
field-set bean?)

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/

[prev in list] [next in list] [prev in thread] [next in thread]