Examining the Struts Framework's Usefulness
To understand what Struts is, it helps first to review the terms defining the Model-View-Controller (MVC) approach to application development (see Figure 1). When creating an application, the Model represents the information—the logic—that connects the information. To a Java developer, these roles are implemented by the storage media (such as database tables or data files) and the Beans which maintain them. To a ColdFusion developer, the model is supported by ColdFusion components and data sources.
Figure 1: The Model-View-Controller (MVC) architecture
The View is the interface used to present the model to users, or obtain input to maintain that model. To a web developer, this View is passed between web browsers and web servers as HTML pages and HTTP requests. Java developers create this interface using JavaServer Pages (JSPs), HTML, and JavaScript. ColdFusion shops use ColdFusion Pages (CFMs), HTML, and perhaps some JavaScript.
The Controller is responsible for directing traffic between and among the Model and View objects. As the View submits information, that information is passed to the Controller, which implements the proper Model object for manipulating or storing the data. The Controller might invoke a new View to provide user feedback on the Model's success or failure to process that information. Likewise, when the View requests information, the request is submitted to the Controller. The Controller calls the necessary Model(s) to get the information and then passes that information to an appropriate View object for display. How—or perhaps I should say where—this Controller function is implemented is what differentiates Model-1 and Model-2 implementations of the MVC design.
A full description of Model-1 and Model-2 MVC implementations can be found in "Designing Enterprise Applications with the J2EE Platform, Second Edition" by Inderjeet Singh, Beth Stearns, Mark Johnson, and the Sun Microsystems Enterprise Team. This book explains that in a Model-1 architecture, application flow is determined by the links embedded in the JSP or CFM pages; whereas in a Model-2 architecture, a servlet (Controller) is placed between the web pages (the View) and the business objects (the Model) to determine program flow.
So now with all that behind us, we can define Struts as follows: Struts is an implementation of the Controller functionality in a Model-2 MVC architecture.
The next logical question to ask is how do you apply these various roles of MVC architecture to the ColdFusion MX environment? And which—if any—of these architectures is appropriate for your project?
Applications created using JSP or CFM pages have a tendency to embed some of the business logic within the current page. Although it's possible to separate logic from Views, which are later combined using includes, it's not uncommon for developers—especially during the final hours of development—to embed small pieces of logic in the View layer. What's more to the point is that the command richness of both JavaServer Pages and ColdFusion MX allows developers to break rules. Because these types of applications are considered non-MVC conforming designs, they do not perform well over heavy loads. Non-MVC applications are perhaps most appropriate for prototypes and small-scale applications.
By using CFMs, which call the business logic defined in ColdFusion Components (CFCs), ColdFusion MX offers a Model-1 MVC architecture. This approach separates the business logic so that business objects can be reused by several areas of an application, or among different applications. Additionally, components can be spread among servers to distribute the processing burden among several CPUs. However, in a Model-1 architecture, application flow is still embedded in the CFM pages, which makes for difficult refactoring and logic reuse.
When you add Struts to a ColdFusion MX environment, you can say that ColdFusion MX supports the creation of a true Model-2 implementation of the MVC design pattern. We could create the Model-2 architecture by creating CFCs that serve the Controller function, but with Struts implementing the architecture is plugged-in rather than hard-coded. This means that business logic and the screens in front of them can be reused by different applications. This design also scales well to support heavy traffic, creates reusable components, and allows parallel tasks in projecting timelines.
From the programmer's perspective, Struts is the traffic cop between and among Views (JSPs and CFMs) and Models (Beans and CFCs). It therefore provides methods for accepting data and passing it to Model objects. It also provides the Model object with destinations to which control should be passed after processing. Each object uses values placed in the various scopes (request, session, or application) to share information and results.
Perhaps if we follow a form submission through the processes you will better understand what Struts does to the process by acting as the "Controller" of our Model-View-Controller architecture. You will see that this approach is quite different compared to other design architectures.
Start with a HTML form sitting in a user's web browser. If we look at the page source, we see that the form's action attribute is something similar to "action=/do/processIt". The user submits this form to the ColdFusion MX server.
The ColdFusion MX server has been set up so that all URLs of the form "/do/*" are redirected to Struts by the Struts Action servlet. This effectively passes the HTML form to Struts, which compares the remainder of the URL (the "/processIt" part) to its mapping definitions to select which Model will be passed the information. To help things along, Struts first loads the form data into a Bean so that the Model can use simple getter and setter methods to process the information.
When processing is complete (typically new information has been stored in the request or session scope), the model tells the Controller which of its possible forwards should be passed the request object (e.g., "I was successful, so forward to a success View" or "I failed, so forward to a please-try-again View"). The Controller then passes the session—with all its values placed in the request and session scopes—to the next Model for further processing, or the next View for presentation.
This map among Models and Views is stored in a configuration file (called struts-config.xml), which Struts reads when it's initialized. Because this information can be changed and reloaded, the application flow can be changed without having to rewrite Model or View components. It is this aspect of Struts that allows developers, page designers, and business-process designers to work and update a project independently and in tandem.
Submit feedback on our tutorials, articles, and sample applications.
