We've followed the Session Facade design pattern, where the action classes handle the interaction between the GUI and our core business logic; somewhat of a sub-controller for the given GUIs to control how we get/put/update/calc data between our Session Beans and our Forms. In addition, the Action classes manage application errors and system exceptions and how these errors should be forwarded to the user. We try to keep most, if not all our business logic in our Session Beans, so business logic can be client independent (not tied to Struts, http, servlets or the like) and sharable across multiple action classes. Needless to say, we attempt to keep our Action classes as thin as possible, delegating business logic/processing to our Session Beans. In addition, we try to keep our client code (GUIs) as thin as possible as well. If a sorting algorithm is needed to present data in a certain way, we provide helper methods that can be called by our Action classes to get data in different ways... this way, these operations are sharable...
So far, this pattern has worked extremely well for us and allows us to partition our application so our business logic is client independent and is manageable. In terms of overkill, well some may see this as an extra layer, however the benefits derived from partitioning these set of processes (sub-controlling interactions between GUI and core business logic) outweigh any concerns regarding extra layers in terms of overall application maintenance and reusability. If you are not using EJBs, you still may want to put core business logic in separate business operation classes, that are not tied to the client (Struts, http, servlets).... I guess it would depend on how large your application is... Just my .02........ -----Original Message----- From: Edward Q. Bridges [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 6:24 AM To: Struts Users Mailing List; Ted Husted Subject: Re: Action an overkill ?? i was a little confused about your original post on this subject, but then your followup seemed to confuse me more. your original post on this subject seems to imply there is an additional layer, distinct from the Action, where business logic should reside. then, your follow up seems to confirm that the business logic should reside in the Action. my original impression about the struts paradigm (being new to it), was that all business logic was coded into the Action. the logic would then make calls to Session, Entity, and Java Beans which would encapsulate the complexities of specific aspects of the business logic. as an approach, this seems to make the most sense, compared to trying to put _all_ of the business logic in some place other than an Action and have the Action call it. what would you say? thanks --e-- On Fri, 07 Dec 2001 05:30:52 -0500, Ted Husted wrote: >Which makes the answer, implement it in the Action first, where it is >easy to do, but more because it *is* business logic, . . . >> So, IMHO, ordering is not something the Action does, or something a tag >> extension does, is something the business layer does. The Action may >> select which ordering has been requested by the client, but when the >> data comes back, it just passes it along. -------------------------------------------- <argo_tec gmbh> ed.q.bridges tel. 089-368179.552 fax 089-368179.79 osterwaldstraße 10 (haus F eingang 21) 80805 münchen </argo_tec gmbh> -------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
