why business logic not written in Action class

why business logic not written in Action class.

Separation of concerns, and easier to test.

still am not clear. can you little bit better explanation.

Separation of concerns

Correct me if I'm wrong but, aren't the Action classes SUPPOSED to be where the business logic goes? You're supposed to separate business and presentation layers. I always thought you didn't want your presentation logic to creep into your actions, and your business logic to creep into your JSPs.

You're wrong. While what you say about presentation is correct, there are other concerns. Putting business logic in actions makes that logic much more difficult to test, and impossible to re-use.

I guess my question would then be, what exactly is "business logic" and where would that go? What is the "logic" that goes into the action classes?

Action classes, ideally, would contain only things related to the web layer. Data wrangling, error handling and redirection, how to report what happens on the business side to the user, etc.

Ok. I guess that makes sense. I've read a lot of things that have simply stated that the Action class is like the Model in MVC and contains the business logic. I've been working through Struts 2 In Action and what they say is, "a Struts 2 action serves two roles. First, an action is an
encapsulation of the calls to business logic into a single unit of work. Second, the
action serves as a locus of data transfer." I guess this makes sense.

"Encapsulation of business calls" is a good way of putting it.

Think of it this way: how can you unit test your business logic if it's all wrapped up in the web layer? (I guess you *can*, but it's needlessly complicated.) And re-using it becomes *substantially* more difficult.

Makes sense. I was looking through the action classes that I've written and most of the "execute" methods call other things.