Presented by Alexey Vedishchev Developing Web-applications with Grails framework American University of Nigeria, 2016 Intro To MVC Architecture

The hard problem in Object-Oriented programming is deciding what objects to have, and what their responsibilities are. Design Patterns describe the higher-level organization of solutions to common problems. Design patterns are a major topic in O-O design. Design Patterns 2

First Appeared Formally in: “A cookbook for using the model-view controller user interface paradigm in Smalltalk- 8” by Glenn E. Krasner and Stephen T. Pope Journal of Object-Oriented Programming, 1(3):26-49 August/September 1988 The MVC pattern 3

MVC stands for Model-View-Controller The Model is the actual internal representation The View (or a View) is a way of looking at or displaying the model The Controller provides for user input and modification These three components are usually implemented as separate components of program. The MVC pattern 4

Most programs are supposed to do work, not just be “another pretty face” ▫ but there are some exceptions ▫ useful programs existed long before GUIs The Model is the part that does the work--it models the actual problem being solved The Model should be independent of both the Controller and the View But it provides services (methods) for them to use Independence gives flexibility, robustness, etc. The Model 5

Most programs are supposed to do work, not just be “another pretty face” ▫ but there are some exceptions ▫ useful programs existed long before GUIs The Model is the part that does the work--it models the actual problem being solved The Model should be independent of both the Controller and the View But it provides services (methods) for them to use Independence gives flexibility, robustness, etc. The Model 6

The Controller decides what the model is to do Often, the user is put in control by means of a GUI ▫ in this case, the GUI and the Controller are often the same The Controller and the Model can almost always be separated (what to do versus how to do it) The design of the Controller depends on the Model The Model should not depend on the Controller The Controller 7

Typically, the user has to be able to see, or view, what the program is doing The View shows what the Model is doing The View is a passive observer; it should not affect the model The Model should be independent of the View, but (but it can provide access methods) The View should not display what the Controller thinks is happening. The View 8

Architecture Diagram 9 View model representation Model business logic Controller user interaction UpdateEvent User Actions SetState Get State Change View

Sometimes the Controller and View are combined, especially in small programs Combining the Controller and View is appropriate if they are very interdependent The Model should still be independent Never mix Model code with GUI code! Combining Controller and View 10

As always, you want code independence The Model should not be contaminated with control code or display code The View should represent the Model as it really is, not some remembered status The Controller should talk to the Model and View, not manipulate them The Controller can set variables that the Model and View can read Separation of concerns 11

Model Domain objects – map to database tables. Constraints - validate fields and order the view. Dynamic - change domain - changes database. Dynamic Finders - not static - automatically generated from finder method name - v.cool. View Template to display domain objects. Can use gsp, jsp or html. Tag libraries - easy to use - can change dynamically. Controller Decides what to do when a view submits and action to the server. “Flash” feature - for messages in the view. Model View Controller in Grails 12

Separation between the data layer and the interface is the key: The view is easily replaced or expanded. Model data changes are reflected in all interfaces because all views are Observers. Better scalability since UI and application logic are separated. Distribution over a network is greatly simplified. Advantages 13

Modularity ▫ decoupling components ▫ allows each component to be versioned independently ▫ worked on by individuals on team (UI person, DB person, etc) Flexibility ▫ multiple Views for one Model (web frontend, desktop frontend, mobile frontend, etc) ▫ replace one component (replace data storage from flat file to database) Maintainability ▫ only change one component where bug exists, less risk in late changes Testability ▫ each component communicates through contract so each component can be unit-tested independently Advantages 14

Spreadsheet application (classic) ▫ same data (model) spreadsheet can have multiple charts (views) ▫ updating spreadsheet should result in updated charts ▫ example of multiple views, single controller, single model Scaling an application ▫ view is desktop or web, model is a flat-file database ▫ updating the database to clustered set of SQL servers ▫ only model needs to take changes for architecture, controller connects to new model and doesn’t know that the model is now backed by several DBs instead of one file Multiple user interfaces to application ▫ web interface, mobile phone interface, point-of-sale interface, desktop interface ▫ multiple views, multiple controllers, single model Example Scenarios 15

GUI Frameworks for desktop applications ▫ Application Kit – part of Cocoa for OS X desktop apps ▫ GTK+ - part of GTK libraries, used in lots of apps ▫ Microsoft Foundation Classes (MFC) – Document/View Architecture ▫ Java Swing ▫ Windows Presentation Framework (WPF) ▫ TK Toolkit – part of Tcl/Tk Implementations of MVC in web-based frameworks ▫ ASP.NET MVC Framework (.NET) ▫ ProMesh.NET (.NET) ▫ Grails (Java) ▫ Struts (Java) ▫ Spring (Java) ▫ PureMVC (JavaScript) ▫ Ruby on Rails (Ruby) ▫ Zend Framework (PHP) ▫ Django (Python) ▫ Pylons (Python) Modern Implementations 16