Some parts of the MailReader are well designed. Others not so much.
Quoting from the Struts 1.2 documentation:

* http://struts.apache.org/userGuide/building_controller.html

----

    The MailReader example application included with Struts stretches
[the MVC] design
    principle somewhat, because the business logic itself is embedded in the
    Action classes.

    This should be considered something of a bug in the design of the example,
    rather than an intrinsic feature of the Struts architecture, or an
    approach to be emulated.

    In order to demonstrate, in simple terms, the different ways Struts can be
    used, the MailReader application does not always follow best practices.

----

A goal for Struts Classic 1.3.x is to make the MailReader a true
best-practices example with multiple plugins for the data access
layer. We've taken the first steps toward that here:

* http://opensource2.atlassian.com/confluence/oss/display/STRUTS/MailReader

To offset streamlining the MailReader, we're adding a "Struts
Cookbook" application with coding examples outside the scope of
MailReader, based on the one Steve Raeburn started here:

* http://www.ninsky.com/struts/

-- HTH, Ted.
http://www.husted.com/poe/

On 9/22/05, Koen Jans <[EMAIL PROTECTED]> wrote:
> The struts design guidelines states that Actions perform the processing
> required to deal with a request (such as saving a row into a database);
> this can be done by logic code embedded within the Action class itself,
> BUT should generally be performed by calling an appropriate method of a
> business logic bean.
>
> Now, in the example, the database is retrieved from the servletcontext
> (why is this? one instance per user?) and the Action classes itselves
> perform the database operations on the database directly.
>
> This seems to me like poor reuseability..
>
> Suppose i want to create a business logic bean, let's say UserHandler,
> wich handles all the user savings and retrievings. So in the Action
> class, i create an instance of UserHandler and let the UserHandler
> perform all the work. If i want to do this, i should pass the database
> along to a method, ex.
>
> userHandler.saveUser(UserDatabase database, String userName, String
> email, ..)
>
> But then i have to pass the database along, losing transparacy..
> Or would this not make any sense at all?
> thanx

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to