I would compare this problem with the EJB's... (even if I do not really like the EJB's).
The DAO corresponds to the Entity-Bean. It should govern the atomar life-cycle of the single Business-Object. Then you have the Session-Bean which implements the use-case-logic. This class contains the logical connections between the business objects. In your setup this layer is missing. I tend to divide the model-layer into a logic-layer and a persistence-layer... hope this helps (and comments will help me to refine my thinkings...) Alexander -----Original Message----- From: Paul Barry [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 15. April 2004 19:13 To: [EMAIL PROTECTED] Subject: Struts, Business Logic, DAOs 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
