MVC ARCHITECTURAL PATTERN


DEVELOPING PROCESS OVERVIEW


PROBLEM

Without separation of concerns a developer has to rely and wait for the feeds of others to complete his tasks. PRODUCTIVITY

SOLUTION

With separation of concerns by MVC he can build applications faster without any involvement of other developers. PRODUCTIVITY ++

MVC

PATTERN? 
ARCHITECTURE? 
FRAMEWORK?

PATTERN


"Each pattern is a three-part rule, which expresses a relation between a certain context (design context), a certain system of forces which occurs repeatedly in that context (recurring design problem), and a certain software configurations which allows these forces to resolve themselves (solution)"

ARCHITECTURAL PATTERN

Fundamental Structural organization for software systems.

Architectural patterns are high-level strategies that concerns large-scale components, the global properties and mechanisms of a system.

"At the highest level, there are the architecture patterns that DEFINE THE OVERALL SHAPE AND STRUCTURE OF SOFTWARE APPLICATIONS. Down a level is the architecture that is specifically related to the PURPOSE of the software application. Yet another level down resides the ARCHITECTURE OF THE MODULES and THEIR INTERCONNECTIONS. This is the domain of design patterns, packages, components, and classes."

ARCHITECTURAL PATTERNS

MVC Pattern

MVC - Model-View-Controller - is a design pattern for the architecture of web applications. It is a widely adopted pattern, across many languages and implementation frameworks, whose purpose is to achieve a clean separation between three components of most any web application.

  • Model: business logic & processing
  • View: user interface (UI)
  • Controller: navigation & input



MVP 

(MODEL - VIEW - PRESENTER)




COMPONENTS

  • The MODEL refers to the data and business functionality of the application.
  • The VIEW is the visual representation of the MODEL and is comprised of the screens and widgets used within and application.
  • The PRESENTER is a component which contains the presentation logic which interacts with the MODEL

THE SUPERVISING CONTROLLER

COMPONENTS

  • The VIEW is the visual components used within an application such as screens and widgets.
  • The CONTROLLER is a component which processes user events and the complex presentation logic within an application.

THE PASSIVE VIEW PATTERN


COMPONENTS

  • The VIEW is the visual components used within an application such as screens and widgets.
  • The CONTROLLER is a component which processes user events and the presentation logic within an application.

PRESENTATION - ABSTRACTION - CONTROL PATTERN 

(PAC)


Description


"The Presentation-Abstraction-Control architectural pattern (PAC) defines a structure for INTERACTIVE SOFTWARE SYSTEMS in the form of a hierarchy of cooperating agents. Every agent is responsible for a specific aspect of the applications functionality and consists of three components: presentation, abstraction, and control. This subdivision separates the human-computer interaction aspects of the agent from its functional core and its communication with other agents."

Components

  • The abstraction component retrieves and processes the data.
  • The presentation component formats the visual and audio presentation of data.
  • The control component handles things such as the flow of control and communication between the other two components.
 

PRG

Post Redirect Get

Instead of returning a web page directly, the POST operation returns a redirection command. The HTTP 1.1 specification introduced the HTTP 303 ("See other") response code to ensure that in this situation, the web user's browser can safely refresh the server response without causing the initial HTTP POST request to be resubmitted. 

AGILE & DESIGN PATTERN

SOLID PRINCIPLE


S : SRP (Single Responsibility Principle)

O : OCP (Open Close Principle)

L : LISKOV (Liskov Substitution Principle)

I : ISP (Interface Segregation Principle)

D : DI (Dependency Inversion)

SINGLE RESPONSIBILITY PRINCIPLE



Which is the single reponsibility of each class?
Single responsibility = single reason for change
A class should have one and only one reason to change
This class does too much. HELP!!


http://blog.gauffin.org/2011/07/single-responsibility-prinicple/

Easy way to follow SRP

Constantly ask yourself whether every method and operation of a class is DIRECTLY RELATED to the NAME of that class.

OPEN CLOSE PRINCIPLE




Open for extension

Close for modification

Which means that you can add new features through inheritance but should not change the existing classes (other than bug fixes)

How to achieve OCP?

TDD = force the system to be testable.
We will have to build abstraction to make the system testable.

Liskov Substitution Principle




If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may substitute objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.)


Solution


Clues fror LSP Violation

Look for a derivative class: Which remove functionality from base class and does less than its base.

not substitutable from base class.

Interface Segregation Principle


No client should be forced to depend on methods it does not use. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

Dependency Inversion


A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
A GOOD architecture is a PLUGIN architecture.



MVC 

ANTIPATTERNS

Circular Dependency

Introducing unnecessary direct or indirect mutual dependencies between objects or software modules

God Object

Concentrating too many functions in a single part of the design (class)

Object cesspool

Reusing objects whose state does not conform to the (possibly implicit) contract for re-use

Yo-yo problem

Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

Magic Pushbutton

Coding implementation logic directly within interface code, without using abstraction

...

http://c2.com/cgi/wiki?AntiPatternsCatalog

REST

Difference between traditional MVC and REST Controller

A key difference between a traditional MVC controller and the RESTful web service controller is the way that the HTTP response body is created. Rather than relying on a view technology to perform server-side rendering of the greeting data to HTML, this RESTful web service controller simply populates and returns a Greeting object. The object data will be written directly to the HTTP response as JSON.

FINAL THOUGHTS 

http://www.garfieldtech.com/blog/mvc-vs-pac
http://blog.gauffin.org/2012/05/solid-principles-with-real-world-examples/

Title

Made with Slides.com