Struts Action Classes - Presentation or Business Logic Layer?

I am proposing that in a system which we are developing that the Struts Action classes be part of the Presentation layer and should communicate with the Business Logic layer via something like a Business Delegate. Someone else has argued that the BD is not necessary as the Struts Action classes should be regarded as part of the Business Logic layer.

I am not taken with this view as this couples the two layers together, with Struts objects in both layers. I think that the business objects should not know about the client, which may be implemented in Struts today but which could change next year. What do you guys think?

I agree with you Roger, in John Carnell's Pro Jakarta Struts book he completely suggests using a Business Delegate to do just what you proposed, decoupling the business logic from the Action classes/Front End.

Mark

I totally agree.

Imagine in a year from now, someone notices that for really complex tasks, a Swing UI will be much more comfortable than a web browser. Then you will be gratefull if you don't have mixed anything web-specific into your business logic.

Strictly speaking, Action classes belong to the Controller layer of MVC. The ActionForm classes belong to the View layer. That said, I agree with your proposal to use a BD. The Action class should be primarily responsible for flow control and should not have any intimate knowledge of the business logic.

We should have a clear demarcation here.

1. Strut's Action Servlet
2. Classes extend Action class.

In the first case, yes, Action Servlet is a one single instance (front controller, singleton pattern class) that does all the routing stuff. Definitely this belongs to the controller of MVC.

In the second case, the classes which extend Action class belong to the business logic category. These would have business logic written inside or codes to call the database.

Thanks,
Guru

I saw long time ago post that all your Struts Action classes belongs to Model and (!) partly to Controller. Personally I, consider this to be the more correct definition.
In my projects, I _always_ work with Business Logic via Business Delegates, and accessing Business Delegates from Struts Action classes.
[ May 04, 2005: Message edited by: Olexiy Prokhorenko ]

I want to back Ilja up here (nothing new) that you want to keep action classes in your controller layer. Ideally the model would never know that you're using Struts or any of the classes that come with it. The model could be reused with another UI or even two UIs at the same time without change.

Originally posted by Olexiy Prokhorenko:
I saw long time ago post that all your Struts Action classes belongs to Model and (!) partly to Controller. Personally I, consider this to be the more correct definition.

The way I see it, it's not a matter of definition, but a matter of choice. Wether the Action classes belong to the model or the Controller/View will, besides other things, influence what kinds of dependencies you tolerate and how the classes will get packaged. Which in consequence will affect the flexibility and maintainability of the whole system.

If the development environment allows it, I actually organize my code in a way that it doesn't allow me to put dependencies to the CV into the M. In Eclipse, for example, this can be done by putting the M into its own project, which the CV project depends on.

Stan already mentioned it above, but I think it can't be stressed enough: don't ever let your model know about what kind of UI is operating it. Never ever. Really. I'm quite serious about this. You will thank me in the future if you follow this advice.

If you don't follow it, you can as well fully drop the whole MVC idea.

Here is an update. The person who suggested that the Struts Action classes should be in the Business Logic layer has now agreed with me that they are in the Presentation layer.

But he does not believe that there should be a Business Delegate, he reckons that the Action classes themselves comprise the interface between the layers. But this, to me, means that the Presentation layer is locked into a Struts implementation. Shouldn't good design give you options rather than constraining you?

What is the return value of the Action.execute() method? It's an ActionForward. What does an ActionForward object do? It determines where to go next, i.e. it controls the flow of the application. Yes, an Action class acts an interface between layers: the Presentation and the Model layer. That is, it knows about Presentation layer objects (ActionForm) and it knows the Model Layer objects (the Business Delegate) that are responsible for processing the information taken from the Form. That puts the Action class squarely in the Controller layer in my book. Ask your guy to heed Ilja's advice: separate concerns, assign reponsibilities appropriately and use a BD.

I mostly see BusinessDelegate as a gift from some server team to some client team. It hides the mechanics of calling the server, but not much else. For example, if you were a JSP/Servlet giant you might not want to know anything about calling remote EJBs. I could give you a BD to hide the tricky bits.

The BD is also a good thing if the protocol might change some day. Suppose I provide a business service to you via remote EJB calls, and one day I decide I could serve "dot net" clients if I changed my API to web services. I could send you a new BD and you'd never have to know what changed.