Most often, the Actions work as an adapter between a view layer and a general-purpose business facade. Because the Actions select a token indicating a result, the Actions tend to be bound to some type of navigational system. A classic Action passes input values to the business facade, and the business facade returns output values, along with any error or status messages. (The latter often being indicated by exceptions.) By creating a generic business facade, we can use it with other view layers (which would include unit tests) that utilize the same business logic, but may implement a different navigational system.
Of course, since S2 Actions are generic, it would be possible to use XWork and Actions as a business facade. But, the problem people often run into as applications grow is that there is not a clear line where the business facade ends and the web adapter begins. At my day job, we're moving the UI for our next application over to Ajax. It's a .NET application, so we are not using Struts, but we are using a business facade based on a port of Commons Chain. The business methods are represented as individual commands, some of which call out to iBATIS.NET while resolving the other business logic. We chain commands together to create a "transaction script" (to use Martin Fowler's term). In our case, Ajax makes the MVC separation very clear. In the last application, the ASP codebehind would make one or more calls to the business facade, to populate the various controls and whatnot. In this application, the various Ajax widgets and whatnot can populate themselves by making asynchronous calls to a JSON-RPC handler. The handler is essentially a servlet that acts as an adapter between the business facade and the Ajax widgets. The cool part is that we are able to use the exact same business facade that we used with the prior application with zero-changes. Instead of the ASP codebehind making the calls, the JSON-RPC makes the same calls on behalf of the Ajax widgets. We're quite happy with the result. But, the key was that we clearly separated the business services from the rest of the application, making them easy to reuse it in a different UI (ASPX versus Ajax). (To be clear, we are not using ASP pages at all anymore. Just HTML pages that call a C# JSON-RPC handler (Jayrock), which I believe is the same sort of thing as DWR.) -Ted. On 2/16/07, Dave Newton <[EMAIL PROTECTED]> wrote:
--- Ian Roughley <[EMAIL PROTECTED]> wrote: > > I'm not sure what you mean by that... it's just a > > class; it happens to be compiled on-the-fly during > > bean instantiation. Not much else is different. > Yes, but it feels to me like you are reaching back > into the business service tier to create classes that > are primarily view tier - just feels backwards to me. Wait, what? Which is the "business service tier"? I'm not convinced that Actions are "view tier," either, since they're really just command pattern implementations... I suppose the result values tie them to the view tier, but... boy, I dunno. Hrm, that'll give me things to think about over the weekend :) Dave
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
