Hi Paul, I would implement "BusinessRule"s (make that "UseCase"s?) objects that encapsulate the BL behind your app. Then, in an "upper" layer, I would implement "TransactionalOperation"s objects that define a transactional operation (thus encapsulating the begin and the end of your transaction), where such concept might encapsulate the execution of 1..n BRs. Then, the same BR could be reutilized from different TOs and your Actions will be able to call the corresponding TO (and obtain the result, if applicable). At least, this is the approach we'll be applying onto the project we are about to begin.
Don't know if it's the best / more elegant / efficient / "whatever"... in any case, I believe it's correct. HTH, Freddy. -----Mensaje original----- De: Paul Barry [mailto:[EMAIL PROTECTED] Enviado el: jueves, 15 de abril de 2004 19:13 Para: [EMAIL PROTECTED] Asunto: 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#acti on_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]
