In the previous section, you learned that a development approach based on jQuery is not a good idea for a large web application.
To move a step forward, we need to decide what's the best option in terms of testable code. The main topic here is the application design; in other words, how we can build our codebase following a general guideline with testability in mind.
In software engineering, there's nothing better than not reinventing the wheel; we can rely on a safe and reliable resource: design patterns. Wikipedia provides a good definition for the term design pattern (http://en.wikipedia.org/wiki/Software_design_pattern):
"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.
Patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system."
There are tons of specific design patterns, but we also need something related to the presentation layer because this is where a JavaScript web application belongs.
The most important aspect in terms of design and maintainability of a JavaScript web application is a clear separation between the user interface (basically, the HTML markup) and the presentation logic (the JavaScript code that turns a web page dynamic and responsive to user interaction). This is what you learned digging into a typical jQuery web application.
According to MSDN's patterns & practices, there are other important aspects involved in the presentation design patterns (http://msdn.microsoft.com/en-us/library/ff647343.aspx):
Document simple mechanisms that work
Provide a common vocabulary and taxonomy for developers and architects
Enable solutions to be described concisely as combinations of patterns
Enable the reuse of architecture, design, and implementation decisions
You have to support user interactions of increasing complexity, involving complex relationships between forms and pages in the user interface
Existing business processes change and you have to present new or modified functionalities to your users
You have to port your application to other platforms or make the application accessible to additional client types (such as mobile devices)
At this point, we need to identify an effective implementation of a presentation design pattern and use it in our web applications. In this regard, I have to admit that the JavaScript community has made an extraordinary job in the last two years. So far, there are tons of frameworks and libraries that implement a particular presentation design pattern.
We only need to choose which framework fits our needs, for example, we can start by taking a look at the MyTodo MVC website (http://todomvc.com/). This is an open source project that shows how to build the same web application using a different library each time.
In this book, we will use Knockout.JS, one of the most popular libraries that implements the Model-View-ViewModel design pattern.
Most of these libraries implement a so-called MV* design pattern (Knockout.JS does this too). MV* means that every design pattern belongs to a broader family with a common root, which is Model-View-Controller. The MVC pattern is one of the oldest and most enduring architectural design patterns. Originally designed by Trygve Reenskaug, working on Smalltalk-80 back in 1979, it has been heavily refactored since then.
Basically, the MVC pattern enforces the isolation of business data (Models) from user interfaces (Views), with a third component (Controllers) managing the logic and user input. It can be described as (Addy Osmani, Learning JavaScript Design Patterns, http://addyosmani.com/resources/essentialjsdesignpatterns/book/#detailmvc):
A Model representing domain-specific data and ignorant of the user interface (Views and Controllers). When a model is changed, it will inform its observers.
A View representing the current state of a Model. The Observer pattern was used to let the View know whenever the Model was updated or modified.
Presentation was taken care of by the View, but there wasn't just a single View and Controller—a View-Controller pair was required for each section or element being displayed on the screen.
The Controller's role in this pair handles user interaction (such as key-presses and actions, for example, clicks), making decisions for the View.
This general definition has slightly changed over the years, not only to adapt its implementation to different technologies and programming languages, but also because changes have been made to the Controller part. Model-View-Presenter and Model-View-ViewModel are the most well known alternatives to the MVC pattern.
The MV* presentation design patterns are a valid answer to our need; an architectural design guideline that promotes separation of concerns and isolation, the two most important factors needed for software testing. In this way, we can test the models, views, and third actor whatever it is (a Controller, Presenter, ViewModel, and so on) separately.
On the other hand, adopting a presentation design pattern doesn't mean that we cease to use jQuery. jQuery is a great library and we will continue to add its reference to our pages, but we will also integrate its use wisely in a better design context.