CSC/ECE 517 Fall 2014/ch1a 1 sj: Difference between revisions
No edit summary |
No edit summary |
||
| Line 44: | Line 44: | ||
==Architecture== | ==Architecture== | ||
===MVC application model=== | ===MVC application model=== | ||
Play follows a typical MVC architectural design pattern of web application development. | Play follows a typical MVC architectural design pattern of web application development. This divides the application into '''two''' broad layers: | ||
*The Model Layer: It handles the business logic of the actual domain problem. | *The Model Layer: It handles the business logic of the actual domain problem. | ||
*The Presentation Layer: This can be categorized into two sub parts. | *The Presentation Layer: This can be categorized into two sub parts. | ||
**The View: It handles the actual GUI of the application | **The View: It handles the actual GUI of the application | ||
**The Controller: It maps the actions on the user interface to the concerned models. | **The Controller: It maps the actions on the user interface to the concerned models. | ||
The '''Model''' refers to the entities involved in the real world domains. It captures the actual data and applies the programming logic to it. The model operates on the raw data and adds "meaning" to it. Generally this data is stored in a persistent storage medium, like a database. Th model interacts with this data by means of a Data Access Layer which is encapsulated by it. | |||
The '''View''' refers to the actual [http://en.wikipedia.org/wiki/Graphical_user_interface Graphical User Interface(GUI)] displayed on the browser. This is the interface with which the user connects to the application. The data is inputted into the application using the interface provided by the view. It is usually displayed in the browser using [http://en.wikipedia.org/wiki/HTML HTML], [http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS] and [http://en.wikipedia.org/wiki/JSON JSON] formats. It acts as the single point of access to the application for the end user. | |||
The '''Controller''' maps the user actions (events) to the concerned models and invokes the required changes in them. It processes the events and affects the behavior of the underlying models. Typically, in a web application, the events generated are HTTP/HTTPS requests. The responsibility of the controller is to act as a filter for the HTTP requests, process them, extract relevant information and pass it to the concerned entities. | |||
Revision as of 17:52, 17 September 2014
Play Framework is a high velocity web development framework for Java and Scala. It uses the Model-view-controller (MVC) architectural pattern for implementing user interfaces. Play is based on a lightweight, stateless and web-friendly architectue written in Scala. The prmary goal of Play framework is to provide a developer friendly development platform for web development.
The major advantage of Play over other Java EE frameworks is its ability to build highly scalable applications. Its reactive model (Reactive Manifesto), thanks to Iteratee IO provides nominal consumption of resources (CPU cores, memory), a major requirement for ascendable and asynchronous applications.
Some of the major names using Play framework are LinkedIn, Klout, TheGuardian, ZapTravel and GILT
Motivation
Play framework
History
The early versions of Play framework can be traced back to early 2007 while it was being developed at Zenexity by software developer Guillaume Bort. The first full version of Play was in October 2009. Later in 2011, Sadek Drobi, co-creator of Play, joined the Play development wagon to release Play 2.0 in conjunction with Typesafe Stack 2.0.
Release History
| Release Version | Date of Release | Features |
|---|---|---|
| Play 1.x | November 2010 - April 2011 | |
| Play 2.0 | March 2012 |
|
| Play 2.1 | Februrary 2013 |
|
| Play 2.2 | September 2013 |
|
| Play 2.3 | May 2014 |
Architecture
MVC application model
Play follows a typical MVC architectural design pattern of web application development. This divides the application into two broad layers:
- The Model Layer: It handles the business logic of the actual domain problem.
- The Presentation Layer: This can be categorized into two sub parts.
- The View: It handles the actual GUI of the application
- The Controller: It maps the actions on the user interface to the concerned models.
The Model refers to the entities involved in the real world domains. It captures the actual data and applies the programming logic to it. The model operates on the raw data and adds "meaning" to it. Generally this data is stored in a persistent storage medium, like a database. Th model interacts with this data by means of a Data Access Layer which is encapsulated by it.
The View refers to the actual Graphical User Interface(GUI) displayed on the browser. This is the interface with which the user connects to the application. The data is inputted into the application using the interface provided by the view. It is usually displayed in the browser using HTML, CSS and JSON formats. It acts as the single point of access to the application for the end user.
The Controller maps the user actions (events) to the concerned models and invokes the required changes in them. It processes the events and affects the behavior of the underlying models. Typically, in a web application, the events generated are HTTP/HTTPS requests. The responsibility of the controller is to act as a filter for the HTTP requests, process them, extract relevant information and pass it to the concerned entities.