Given that SaaS apps have always been view-centric and have always relied on apersistence tier, Rails’ choice of MVC as the underlying architecture might seem likean obvious fit. But other choices are possible, such as those in Figure2.9excerptedfrom Martin Fowler’s Catalog of Patterns of Enterprise Application Architecture. Appsconsisting of mostly static content with only a small amount of dynamically-generated content, such as a weather site, might choose the Template Viewpattern.The Page Controllerpattern works well for an application that is easily structured asa small number of distinct pages, effectively giving each page its own simplecontroller that only knows how to generate that page. For an application that takesa user through a sequence of pages (such as signing up for a mailing list) but hasfew models, the Front Controllerpattern might suﬃce, in which a single controllerhandles all incoming requests rather than separate controllers handling requests foreach model. Figure 2.9: Comparing Web app architectural patterns. Models are rounded rectangles, controllers arerectangles, and views are document icons. Page Controller (left), used by Sinatra, has a controller foreach logical page of the app. Front Controller (top center), used by Java 2 Enterprise Edition (J2EE)servlets, has a single controller that relies on methods in a variety of models to generate one of a
collection of views. Template View (bottom center), used by PHP, emphasizes building the app aroundthe views, with logic in the models generating dynamic content in place of part of the views; thecontroller is implicit in the framework. Model-View-Controller (right), used by Rails and Java Spring,associates a controller and a set of views with each model type.Figure2.10summarizes our latest understanding of the structure of a SaaS app.
Figure 2.10: Step 2a has been expanded to show the role of the MVC architecture in fulfilling a SaaS apprequest. SummaryThe Model-View-Controlleror MVC design pattern distinguishes modelsthatimplement business logic, viewsthat present information to the user andallow the user to interact with the app, and controllersthat mediate theinteraction between views and models. In MVC SaaS apps, every user action that can be performed on a web page—clicking a link or button, submitting a fill-in form, or using drag-and-drop—iseventually handled by some controller action, which will consult the model(s)as needed to obtain information and generate a view in response. MVC is appropriate for interactive SaaS apps with a variety of model types,where it makes sense to situate controllers and views along with each type ofmodel. Other architectural patterns may be more appropriate for smaller appswith fewer models or a smaller repertoire of operations.