MVC architecture is a well-known and a famous architecture. In an application, if there is a view (for example, a form to create payment into a system) and a user would use it to interact with the system, MVC architecture comes as the default and preferred architecture. It is the favorite architecture to model our application so that the presentation logic can be separated from the business logic. In this chapter, we will look at the MVC architecture in general, and understand how it is mapped to Sencha MVC Architecture.
In this, and the subsequent chapters, we will be demonstrating the concepts using some functional code for which the following softwares are required:
- Eclipse 3.3 or above with JEE (for example, Helios) and JavaScript (JSDT) support
- Oracle Java JDK 1.5 or above
- Ext JS 4.1 library
- Sencha Touch 2.0 library
- Android SDK
- ADT plugin
- Apache Tomcat 6.0 or above
Before we get any further, we would need a development environment to be set up, so that we are able to build, deploy, and test the application. For brevity, we will not be covering how to set up the development environment in detail. The following are the high-level steps to get the project set up:
- Create a Dynamic Web Project workspace in Eclipse.
- Create a ch01 folder under WebContent where we will be keeping the code related to this chapter.
Tip
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com . If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
After creation, your project should look as shown in the following screenshot:
- In Eclipse, go to Window | Preferences.
- Expand Server, go to Server Runtime Environments, and add an entry for
Apache Tomcatshown as follows:
- Go to the Servers perspective and add SenchaArchitectureBook to the Configured list, shown as follows:
- Now you will be able to publish and start the server to see that the project is deployed successfully. You should be able to access the
http://<host>:<port>/SenchaArchitectureBook/URL to access the application.
Throughout this book, for the parts referring to Sencha Touch, we will be using the WebKit browsers, for example, Chrome and Safari, on the desktop to demonstrate the concepts. However, if you intend to test them on the real device, the steps would be more involved ones and you can refer to Chapter 1, Gear up for the Journey from the book Sencha Touch Cookbook, Packt Publishing, for detailed steps to set up the environment for Android, iOS, and Blackberry devices. Also, the book assumes that you have done some level of Ext JS or Sencha Touch development and are aware of the components and the programming model of Sencha.
The MVC architecture is all about organizing the code in the form of models, views, and controllers. Models maintain the state of the application, views take care of the presentation of the application state, and controllers provide the much needed functionality to handle the user action and carry out the business logic execution as part of it, which changes the application state. The complete interaction between the pieces—model, view, and controller—is depicted in the following diagram. The solid lines show the flow of logic in terms of method invocation, whereas the dotted lines show the flow of events:
The previous diagram depicts the holistic view of the MVC architecture and how the different pieces of the architecture interact with each other in order to address the specific goals that the architecture promises to address. In this book, we do not intend to redefine and explain the complete MVC architecture. However, you may read more about the architecture at http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller.
Traditionally, in a web application, MVC architecture has been implemented on the server side to keep the view logic away from the business logic. In a typical web application, the server side code is structured in the form of model-view-controller to benefit from the structure to make the application more maintainable, allow parallel development, align the application with the Progressive Enhancement goals, and so on. In this case, the view code takes care of sending the (X)HTML, CSS, and JavaScript to the browser as part of the response in order to show the desired view to the user (for example, a grid showing a list of users with a button to edit the user address). The browser renders the HTML to show the content using the mentioned HTML tags (for example, a <table> tag to show the users list), uses CSS to style the content (for example, show the alternate rows with a different color), and uses JavaScript to add interactivity to the view and take care of the behavior (for example, on clicking the Edit button, showing a form to edit the user address). This has been depicted in the following diagram where the complete MVC is implemented on the server side, whereas on the browser side, JavaScript, CSS, and HTML is used:
Implementation of the previous architecture cleans up the server-side code. However, the browser-side code remains very messy with the HTML, CSS, and JavaScript intermixed. This gets multiplied when a considerable amount of code is written to run inside the browser, to render the view, and handle the interactions with the user, for example, as in Rich Internet Applications (RIA) . In addition to that, given the flexibility JavaScript offers, it makes the matter worse where people do things such as use the variables without defining them, and write functions and use them without worrying about writing object-oriented JavaScript. The need for the code that runs inside the browser does not differ much from the one that runs on the server side, hence the development principles (maintainability, reusability, and so on), which apply to the server-side code, also apply to the browser-side code. HTML and CSS form the view, JavaScript becomes the controller, and the objects, containing the state of the UI, form the model.
Effectively, there is a need to have two MVC patterns in the application, one on the browser side and the other on the server side, to reap the complete benefit of the architecture. The following diagram depicts browser-side MVC architecture and how it would interface with the server-side MVC:
View is the code that produces and renders HTML tags and applies CSS to them (for example, producing the <table> tag to show the users list with the alternate rows highlighted with a different color). Model contains the state of the application (for example, the list of users with their address details) in the form of one or more JavaScript objects/variables. Controller is a part of JavaScript taking care of the behavior part of the UI (for example, the onclick handler of the Edit button). Cache usually maintains the collection of models and provides a convenient way for the browser-side application to fetch the state and state information.