The Action would call the business logic, as opposed to the view. The actual code resides in the business layer, but there would be a method call in the Action.
People have been known to code the actual business logic into an Action, but have usually lived to regret it. If data were stored in a HTTP Session, the Action would retrieve the data and pass the salient facts to the business layer. It is strongly recommended that all business logic reside in classes outside the Action, so that they can be used in other environment, and properly tested with tools like JUnit. So, in a Struts application, the Action would call the business methods, but not implement them. Generally, this is not any more work, since by the time you put the business logic into an Action, the method is overly long. To break it up, you really need to insert "helper methods". Since Actions are multithreaded, you need to pass everything on the stack. And if you are passing it on the stack, it's just as easy to pass it to another class. "Edward Q. Bridges" wrote: > > 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-- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
