In Struts, the Front Controller and Dispatcher are combined. Which begs the quesion:
Do you actually miss a Front Controller, which provides a centralized access point for presentation-tier request handling? Or do you just miss a Dispatcher, which selects the views to handle the response. (Struts comines these into something J2EE Patterns calls "Service to Worker".) Which is to say, do you need to do something special with each request, or is that you just need more help in selecting the response? > I was wondering if any of you knew a Struts like > framework in the .NET world. Maverick has a .NET version of a Struts-like framework, but we haven't been using it. > how do you use ASP.NET? We've been setting our workflows up as panels. One of our pages might have a dozen different panels, which are turned on and off as a client proceeds through a workflow. For the most part, the panel approach lets us get away without a Dispatcher. Pages lead from a main menu down to a mulit-panel work flow, and then back to the main menu. What I started to miss was the centralized Application Controller features of Struts. Features like * command selection * input validation * text formatting * message handling * fault trapping * type conversion * logic processing * control population and harvesting If you think about it, none of these features need to be tied to a particular presentation layer technology. Most of the featuires are found in Struts, and some other frameworks. (I think of Struts as the "unabridged" framework. Many others do what you need, but Struts does it all.) ActionMappings select a command. ActionForm validates input. ActionErrors handles messages. ExceptionHandler catches any runtime faults. BeanUtils converts types and formats text (to a degree). Action processes logic. Taglibs populate controls, and the ActionForms harvest input (using JavaBeans as transfer objects). What we are starting to do is use the inheritence properites of the Page Controller for dispatching, and then calling a Controller from the code-behind. So instead of the Front Controller deciding which Command to call, the code-behind decides for itself which Command it needs to call. We're pushing as much logic up into the Application Controller as we can. We like to test-first, and so we want to test as much of a transaction script as possible before plugging it into the presentation layer. What's left for the Code Behind is bundling up the input, passing it to the appropriate Command, unbundling the output, and then turn on or off the appropriate peansl If you get past the trees, and into the forrest, it's starting to feel a lot like Struts again :) -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
