I'm not sure about the best practice,but I would use
an application specific Controller
(Controller/Mediator pattern)class to perform the
logic. I use a controller class for all related
operations in use case(s) /subsystem.It controls all
interactions between the UI and business layers.
In my Action class, I would call the method in my
controller class, which in turn calls the DAO method.
eg.
in Action class
widgetController.deleteWidget(user,widget);
in WidgetController class,
//logic for checking user type and issuing delete...
......
widgetDAO.deleteWidget(widget);
HTH,
Shyam
--- Paul Barry <[EMAIL PROTECTED]> wrote:
> I have a question about business logic. The best
> way I can think to
> explain this is with an example. I know this is
> kind of long, but I am
> trying to keep this as simple as possible while
> still being able to
> illustrate the point. Let's say I have Users and
> Widgets. I would have
> Business Objects for each one, something like this:
>
> public User {
> public int getId();
> public boolean isAdmin();
> }
>
> public Widget {
> public int getId();
> public User getCreator();
> }
>
> Now assume I am using a DAO like this:
>
> public WidgetDAO {
> public void delete(int id);
> }
>
> Assume the implementation of this DAO would delete a
> row from the widget
> table in the database. So using struts I would have
> an action with a
> method like this:
>
> execute(...) {
> WidgetDAO.delete(widgetId);
> }
>
> Assume the widgetId came from an ActionForm, the
> details are irrelevant.
> The point is this would all work fine, you could
> call the action with
> a URL like /deleteWidget.do?widgetId=4 and it would
> delete widget 4.
> Also, assume there is other logic already handling
> logging in the user
> so there is a UserBO object in a session attribute,
> which is used to
> populate the creator property of the Widget.
>
> But now let's say I have 2 business rules:
>
> 1. users that are admins can delete any widget
> 2. non-admin users can only delete widgets they
> created
>
> So specifically from the objects above, you can
> delete a widget if
> user.isAdmin() returns true or
> widget.getCreator().getId() ==
> user.getId(). The question is where should this
> kind of logic go?
>
> You could get away with putting it in the action,
> but in a real world
> application this type of logic would be much more
> complicated and
> probably get re-used across different actions. The
> Struts guidelines
> even say this:
>
> "Rather than creating overly complex Action classes,
> it is generally a
> good practice to move most of the persistence, and
> "business logic" to a
> separate application layer. When an Action class
> becomes lengthy and
> procedural, it may be a good time to refactor your
> application
> architecture and move some of this logic to another
> conceptual layer;
> otherwise, you may be left with an inflexible
> application which can only
> be accessed in a web-application environment."
>
>
http://jakarta.apache.org/struts/userGuide/building_controller.html#action_classes
>
> I doesn't seem like this logic belongs in the DAO
> either, because if you
> don't want that kind of logic mixed in with code
> to get the data out
> of the database. Does it belong in the business
> objects, maybe by
> expanding the Widget object like this?
>
> public Widget {
> public int getId();
> public User getCreator();
> public boolean canDelete(UserBO);
> }
>
> And then canDelete would in turn call a DAO to check
> that? Or would a
> separate layer be better, like this:
>
> public WidgetLogic {
> public boolean canDeleteWidget(User, Widget);
> }
>
>
> Are there any best practices or sample applications
> that you know of
> that have a good example of a business logic layer?
>
>
>
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
