MVA Overview
Contents |
[edit] MVA Overview - What you need to know:
- The Model View Adapter (MVA) pattern is a next generation application model Bungee Labs has created to enable richer, more responsive user interactivity, delivered 100% via standard web browsers without the need for plug-ins.
- Bungee Connect employs the MVA pattern to
i) dramatically reduce the complexity typically involved in rich UI application construction
ii) enable the automation and built-in state management to support rapid visual feedback for user interactions and model changes
iii) increase application modularity and maintainability, making individual developers and teams using Bungee Connect highly productive
- Similar to the Model View controller ((MVC)) pattern, MVA separates business logic (the Model) from presentation (the View). Unlike MVC, Bungee’s MVA approach lets developers efficiently manage and control the volume and range of screen activity, user gestures and service orchestrations expected of rich client-side web applications.
- A key principle of MVA is the absolute separation of Model and View, in contrast to most large MVC-pattern implementations, which are prone to co-mingling of special case logic in all three domains.
- Adapters, the A in MVA, act as controller agents without requiring the developer to specify the controller instance logic each time Models and Views are required to interact. Adapters separate the Model and View completely without any co-mingling, and manage all interactions, updates, and flow of control. Bungee Connect provides a rich set of adapters, which can be combined to facilitate a broad range of user interactions, updates, data transformations, and flow of control scenarios. Adapters act as connector agents and strictly enforce the Model-View separation without compromising control or flexibility. Views have a single, high-level binding to a Model element, such as a field, and the adapter enables binding and customization of that data. Adapters connect the Model to different interactive elements within the View such that they are managed, monitored and updated in a just-in-time, granular fashion without creating any explicit interdependency between Model and View.
[edit] How MVA differs from MVC:
Like its predecessor, Model View Controller (MVC), the Model View Adapter (MVA) pattern helps developers manage the complexity of applications having multiple ways to access and/or update a centralized business process or data source.
The MVC pattern proliferated when "page-at-a-time" interaction for web applications was the norm, due to the technical constraint of completing full page, round trip, HTTP requests. (For Example: a user fills out an ecommerce shopping cart with product, address and payment information and presses submit, and receives a confirmation page in response.) When designing traditional, full-page-refresh web applications of this type, controller logic can be relatively simple. But this simplicity has given way to complexity as AJAX has become more popular and end-users have come to expect more interactive interfaces delivered through the browser. With richer user web interfaces, the number of interrelationships that need to be maintained, synchronized and reflected in user interface presentation and feedback multiply, making the interaction between View and Model much more difficult to implement and manage.
The MVA pattern creates a much cleaner separation of the Model and the View by flattening the structure from a triangular one (in MVC) to a horizontal hierarchy (in MVA).
Flattening the architecture of the applications created using MVA decreases dependencies so there is no bleeding of code across definitional node boundries (e.g., between the Model and the View, or between the Controller and the Model as often occurs in applications built using MVC). Use of the flat hierarchy provided in MVA allows for increased cleanliness in coding and easy reuse of components built using MVA.
For example, in an application like Bungee Connect’s WideLens reference application, the range of different user actions is quite broad, and interactivity and user feedback are pervasive throughout the application. In a traditional MVC pattern, the developers would have to design, code and manage each of these interaction patterns specifically for each instance of the control. In addition, because MVC does not typically deal with state management/flow or automation, developers would have to create the facilities to keep track of the global implications of all permutations of Views.
In Bungee's MVA implementation these connections and state information flows are managed by Bungee Connect adapters. Because adapters themselves may be reused across the application, MVA dramatically reduces and even eliminates entirely the typical controller logic required by traditional MVC platforms. The code that MVA obviates relative to typical MVC implementations is in large part the un-manageable “glue” code that is not easily encapsulated for reuse in other parts of an MVC application.
Generally in MVC implementations, the controller logic and the overall communication protocol between Model, View and Controller (sometimes called the "wire-up") are largely left to the developer to design and implement. The developer is responsible for defining and managing the ongoing enforcement of separation boundaries. The policies defining the Model/View separation are easily and inconsistently compromised by developers both during initial development and over the life-cycle of an MVC-based application - resulting in blurred distinctions between Model, View and controller code areas , leading to cumbersome application performance and increasingly complex development requirements.
For developers familiar with MVC, the two design patterns will seem conceptually similar. The biggest differences are:
- in MVA there is a well defined separation between Model and View (the Model never directly updates the View or vice versa)
and - in MVA the event driven, data binding, auto-updating capabilities are implemented and provided by Bungee Connect's adapter machinery
This automation provisioned through Bungee’s implementation of MVA enables developers to rapidly create responsive AJAX interfaces without creating and managing triggers, listeners/observers, or other polling and event management facilities. Using MVA, the flow of state can be fully automated, from the UI elements presented in the browser all the way back to the server-side Model objects, and back out to the UI, including the necessary transformations of state and data formats normally required when associating Model data in multiple presentation contexts.
One very powerful capability of the MVA pattern relative to MVC is the ability of the View to dynamically tailor itself based on the runtime states (as communicated to it by the adapter) of the objects in the Model. The presentation that a single View produces can depend on the instance data found in the Model on a just-in-time basis as that data is “bound” to the View. The View can continue to automatically change during the life of user interaction as the underlying Model state changes, either through user directed interaction (that causes state to change) or via Model logic that update its state appropriately. This means that Views bound to Models updated by live web services, databases or other time-variant data are automatically updated as the underlying data sources update.
[edit] Summary: The Benefits of MVA for Developers
- You write a lot less code. BungeeConnect handles event management, state management, data binding, update and flow of control logic
- The different parts of your application stay truly isolated. Add a new set of Views and interactions and your Model stays the same. This increases reuse of code developed to define forms, adapters, and business logic.
- Your web pages (and the rest of your application) are more portable to different contexts (languages, locales, devices and form factors)
- Model ==> View and View ==> Model updates are automated, customizable and optimized, i.e. updating a single Model field bound to 10,000 form instances does not trigger 10,000 page refreshes, but instead updates only that field within those pages.
- Business logic (including validation) stays securely in the Model (therefore the server) where it belongs. There is no opportunity for the application logic to "bleed" into the View's HTML or javascript.