Comparing Web Actions and GuangChun Frameworks: Modifying MVC for Web Apps - Prof. Vernon , Study notes of Software Engineering

Download Comparing Web Actions and GuangChun Frameworks: Modifying MVC for Web Apps - Prof. Vernon and more Study notes Software Engineering in PDF only on Docsity! Modifying MVC for Web Applications Adam Ogle Fall, 2008 Research Methods A Web application is a relatively new type of application that resides on a remote server and interacts with multiple users on remote computers. Because of the stateless nature of the hypertext transport protocol (HTTP), traditional application architectures must be modified in order to maintain state on behalf of an application’s users. One architecture that appears to be easily modifiable for web application use is the Model View Controller (MVC) design pattern. The MVC pattern represents a major departure from traditional strategies for developing interactive applications. Most interactive (traditional and web) applications use a procedure-based approach to manage user interactions: they retrieve data from storage, display this data, retrieve users’ changes, and update storage. This approach makes it difficult to change the application’s user interface independently from its typically more stable business logic. The approach also obscures the application’s business rules, making them more difficult to maintain. The MVC pattern separates an application’s business logic from the application’s user interface. This separation is accomplished using three kinds of elements: controllers, models, and views.  Controllers receive user requests from views, such as button clicks, in the form of messages. Controllers then respond by translating a message into a series of function calls that may modify the model or update a view.  Models implement an application’s domain logic, also known as its business logic. Models interface to controllers through function calls that manipulate and retrieve the model’s state.  Views present content to users. Views do not implement business logic: they merely present model-generated state and configure controller-generated messages for display. -1- Separating an application’s presentation—i.e., its views—from its data management logic—i.e., its controller(s) and model(s)—allows controllers and models to be tested independently of the user interface. This separation also allows views, controllers, and models to be modified independently from one another, so long as their API’s remain stable. In practice, however, changes to controllers and models typically affect these components’ interfaces. An update to a model will usually produce changes in an application’s controllers and views. Similarly, an update to a controller will usually produce changes in an application’s views. This loose coupling of views to models is not possible when multiple applications manipulate and modify shared content. Shared content becomes an issue, for example, when different applications post messages to a shared log. Ideally, it should be possible for a real-time log viewer’s view component(s) to respond directly to these updates, but pure MVC does not allow for this. A work-around for this problem involves creating a central model and applying an Observer design pattern to it. Event handles are added to the central model, which allow the model to signal changes to the applications that use this model. Model functions that change data are responsible to raise an event related to the change. The applications’ views are responsible for attaching to the event handle and implementing the necessary update logic. For the real-time log viewer, a change of the log’s modification date should fire an update event. Subscribing views should then query this model for the log’s entries. In more complex applications, more specific event handles can be generated to reduce the amount of unnecessary view updates and model queries. In “Objects and the Web”, Alan Knight and Naci Dai present an object-oriented approach to creating maintainable web applications. Knight and Dai contrast their approach with the “typical”, rapid- development-based approach to software development, which, they say, produces monolithic and poorly differentiated applications. According to Knight and Dai, web applications can be decomposed into four parts, which handle an application’s inputs, application logic, business logic, and outputs (Dai & Night, 2002). The input logic is responsible for accepting and validating input strings, and possibly converting them to other -2- weather tracker, and search box. Depending on the user request, different applets could appear on the page, even in different locations. The other variation, action context, allows an action’s interpretation to depend on the controller that executes an action. The action context pattern supports the use of generic actions, such as add and delete, that vary by page. This is similar to defining abstract functions for concrete classes to implement. The variations enhance an application’s flexibility, while increasing its complexity. In “A Novel Web Application Frame Developed by MVC,” authors GuangChun, Lu, and Hanhong describe another MVC-based web application framework. This framework is divided into three elements that closely resemble MVC: a SYSController, Model Center, and LPM Center. The SYSController’s role is similar to the controller’s role in the MVC framework: the SYSController determines the user-requested action, and then directs the model to do that action. The SYSController, however, communicates with the controller using a shared file, rather than a function call. This file is an XML file that stores valid (actions, function calls) pairs in a tree. Each of this tree’s interior nodes store function calls that are common to all of that node’s children. For example, a “create student” and “create teacher” node might share a parent node with a stored function call that checks the requesting user’s permissions. This strategy, in effect, shifts responsibility for interpreting requests to the model, allowing actions to be created or changed without modifying the controller. Once it determines the function calls for the user-requested-action, the SYSController wraps the function calls in messages and passes them to the Model Center. The Model Center is similar to MVC’s model element: it acts as a front for a database that maps the function calls to appropriate business logic elements. Upon receiving a message, the Model Center retrieves all needed business logic elements and executes the requested function calls. Once it executes the function calls, the Model Center wraps the results in another message and passes it to the LPM Center. The LPM Center, the framework’s last element, manages a collection of view elements. The LPM Center uses a database to retrieve these views, thereby removing the views -5- from the framework code. After receiving a message from the Model Center and determining which view to render, the LPM Center populates this view’s data fields and sends the view to the client’s browser. The authors suggest a modification for the Model Center to make it scale better for larger websites. Currently, when the web application framework processes an action, a new instance of a Model Center is instantiated. While this is acceptable for small web applications, larger applications cannot tolerate the inefficiency. The suggested modification instantiates Model Center once for all clients, adding a queue to accept incoming messages from all clients, thereby eliminating duplication and allowing for the parallel processing of queue items. While the task of indicating which functions can be done in parallel is involved, parallelizing processing would increase throughput, especially if most actions are parallelizable data queries rather than data updates. While the Web Actions and GuangChun frameworks appear to be competing architectures for a web application framework, they are targeted at different sizes of web applications. Night and Dai’s framework is a simple translation of MVC to the web platform with little overhead. This is appropriate for small applications where the risk of the framework being larger than the actual presentation and data management might occur. For larger applications, GuangChun, Lu, and Hanhong’s framework is more desirable, as it seems more robust and less coupled to the specifics of any web application. The framework would be implemented once (separate from the actual applications) and tested thoroughly— reducing the testing required in future applications. Testability combined with the modularity provided by different data stores holding models, controllers, and views allow for a more scalable framework. Despite these differences, both applications offer the ability to have the presentation be developed in parallel to the data management due to the separation of the two components. They both approach to web design represents a mix of layered and object oriented strategies for application design, which is better than an unstructured application. Unfortunately, both architectures yield larger applications than non-object-oriented design approaches, but the resulting architectures simplify testing and maintenance, which are generally the more expensive processes of software engineering. -6- In “Building User Interfaces for Object-Oriented System,” Alan Holub, a critic of the MVC architecture, argues that MVC is not object oriented and is not a suitable application-level architecture. In Holub’s view, a sound object oriented design is one whose classes hide their implementations, including their data. Holub regards “get” and “set” functions, which return data private from an object, as violations of good OO design. Instead of asking an object for data to manipulate, a client object should ask that object to manipulate data on the class’s behalf. By only allowing interaction with the object through “manipulation request” functions, the object’s internals can change without affecting other classes. This encapsulation includes user interface (UI) elements: a class should be responsible for managing how it presents itself to a UI (whether GUI or CLI). If any of these principles are violated by any of a system’s objects, then the system is not object oriented. When testing the MVC architecture’s “object oriented-ness” against Holub’s definition of object oriented, MVC fails because “there’s just too much data flowing around the system to be maintainable” (Holub, 1999). MVC’s use of cross-cutting layers to separate presentation logic from business logic runs counter to Holub’s principle that objects should manage their own interactions with a UI. Without “get” and “set” functions, MVC will not work as it cannot extract the data from the business logic objects for a view to render. Furthermore, the code to retrieve and render data is separated—this becomes an issue when maintaining the system as code must be updated in at least two locations. With an object oriented system, though, the change would be contained within a single class. Because of the architecture of MVC, it seems difficult for it to conform to Holub’s definition of object oriented. Unfortunately, Holub’s view on how web applications should be designed is unclear from his presentation. In a follow-up article entitled “More on Getters and Setters,” Holub clarifies his view on object-oriented application design. Holub’s idea that a client object should ask an object to do a task is easy to accept when applying it to business logic objects. A client object should not ask for as employee’s wage, increment it by an amount, then store it back in the employee; a client object should request that employee’s wage be increase by an amount and let the employee object handle the actual incrementing. The problem with Holub’s view arises when attempting to design objects that handle how -7- The view contains a single public function, named “.render()”, that renders the page to the browser. For consistency, a view would have an abstract base class that is responsible for rendering the page’s default look (header, footer, navigation placement). Each concrete view would then add any extra data that needed to be rendered to the screen by retrieving the needed business logic objects (using importers or parameters passed to the function) and call each object’s export functions as needed. If an object needs to display a form, a different exporter would be used—which would be paired with a form importer for the next message sent to the message receiver. Consider a simple web portal that allows a user to specify widgets on their screen. When a user requests their page, the controller could load a user through the user’s importer that reads the user’s cookie. Once the importer reads the cookie, a query would be made to the database to retrieve information on all the widgets the user has selected for display. Each widget would be instantiated with its own importer, using the database’s retrieved data. The controller would then call a view’s render function, passing it the user object. The view would then render the portal’s header and call the user’s export using a default portal view exporter. The exporter would be responsible for displaying all of the user’s widgets by calling each widget’s export. Finally, the view would render the portal’s footer, and the page will be complete. -10- References Dai, N., & Night, A. (2002). Objects and the Web. IEEE Software , 51-59. GuangChun, L., Lu, W., & Hanhong, X. (2003). A Novel Web Application Frame Developed by MVC. ACM SIGSOFT Software Engineering Notes , 7. Holub, A. (1999, July). Building user interfaces for object-oriented systems. Retrieved September 18, 2008, from JavaWorld.com: http://www.javaworld.com/javaworld/jw-07-1999/jw-07- toolbox.html Holub, A. (2004, January 2). More on Getters and Setters. Retrieved October 16, 2008, from JavaWorld.com: http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox.html? page=1 Microsoft Corp. (2008). Model-View-Controller. Retrieved September 28, 2008, from Microsoft Developer's Network: http://msdn.microsoft.com/en-us/library/ms978748(printer).aspx -11-