INTRODUCTION TO DESIGN PATTERN
O C O O S G A
ASP.NET MVC
Jaffal Hasan
November 2009

AGENDA
Design Patterns Overview
MVC Design Pattern
MVC vs. ASP.NET
Layered Application Example
MVC vs. Layered Application

DESIGN PATTERN OVERVIEW
Set of guidelines
Provide solutions to common software design
problems
bl
Consists of one or several software design
elements such as modules, interfaces, classes, objects, methods,
functions, processes, threads, etc.,
Relationships among the elements, and a
behavioral description
Example design patterns: Model/View/Controller

DESIGN PATTERN OVERVIEW
Advantages:
Improve the structure of software
Simplify
Si lif maintenance
i t
Shared language for communicating
Separation of concerns
Minimize logic needed in views
Enhance testability
Reduce development time
Easy to customize applications
Disadvantages:
Design pattern can be overkill in Simple UI

GOALS
• Separation of concerns
• Decoupling the layers and components
• R d i
Reducing d
development time ( multi processes at time)
l i li i )
• Testability
• Flexibility
Fl ibilit
• Minimal Code in UI
• Changes in layers: DBMS
• Change or use multiple platform to present data (mobile – web
..)

WHAT IS ASP.NET MVC?
A new Web Application Project type
Simply an option
Not
N a replacement for W bF
l f WebForms
Builds on top ASP.NET
Manual vs. Automatic Transmission
Existing ASP.NET features such as master
pages, web controls, validation, membership
integrated.

WHAT MVC IS NOT ?
Not the new Web Forms 4.0
Not replacing Web Forms, but Adds to it
Not a whole new engine but sits on ASP.NET
engine

WHAT MVC IS?
Maintain Clean Separation of Concerns
Extensible and Pluggable
Great integration within ASP.NET

MVC
Model View Controller
• All b i
business • UI • H dl and
Handles d
logic response user
• ADO.NET, interaction
Linq, Linq to • Work with
SQL model to
retreive
information
and select
view to render
with model
data
• Input logic
p og c

MVC
Model

MVC FLOW

MVC FLOW
Controller
Request
Step 1
Incoming request directed to Controller

MVC FLOW
Controller
Model
Step 2
Controller processes request and forms a data
Model

MVC FLOW
Controller
Vi
View
Step 3
Model is passed to View

MVC FLOW
Controller
View
Step 4
View transforms Model into appropriate output
format

MVC FLOW
Controller
View
Response
Step 5
Response is rendered

MVC : MODEL – VIEW - CONTROLLER

REQUEST FLOW –DETAILED
Request
HTTP Http
Routing Controller Response
Handler
Route View
Route View
Handler Engine

MVC VS. “CLASSIC” ASP.NET
Classic ASP.NET MVC Framework
Request Data Request Data
Code
Postback
behind REST MVC

MVC VS. “CLASSIC” ASP.NET
MVC is based on ASP.NET framework
i b d ASP NET f k
REST model versus the postback model of classic
ASP.NET.
Each page is split into two distinct components -
controller and view - that operate over the same
model of data.
This is opposed to the classic code-behind model
where no barrier is set that forces you to think in
terms of separation of concerns and controllers and
views.
A good developer could achieve separation of concerns
even without adopting MVC and its overhead.
p g
MVC is a model superior to a properly-done code-
behind for its inherent support for test-driven
development.
p

REST ? Set of guidelines
REST is an architectural pattern that defines
how network resources should be defined and
addressed in order to gain shorter response
times, clear separation of concerns between the
y
front-end and back-end of a networked system

WHAT? NO MORE POSTBACKS!
The MVC Framework
Doesn't support classic postbacks and viewstate
Doesn't consider any URL as th endpoint to a
D 't id the d i t t
physical server file to parse and compile to a class.
In ASP.NET, you have a 1:1 correspondence between a URL
and a resource.

WHY MVC?
Very Clean separation of Concerns
Unit Testing
Model that leads you down a maintainable path
(prevent spaghetti code)
Clean URL and HTML
Cl URLs d

CLEAN URL
Url no longer points to the view/aspx page
A Url maps to a controller class
Allows more flexibility to map Urls
Url routing engine, Route table
www.arabiagis.com/software/powermap
Or
www.arabiagis.com/software.aspx?id=23

ROUTING ENGINE
URLs -> application -> Controller Action
Construct outgoing URLs
Constructed URLs can be used to call back to
Controllers/Actions

LAYERED APPLICATIONS SOUNDS GOOD
Layered application design concept sounds good,
but the problem is when it's time to code it.
Let’s See
L t’ S an example l
Presentation
Layer
aye
BLL
DAL

AL THEYAB FLIGHTAVAILABILITY.ASPX
RE-VISIT
Is the code
Maintainable ?
Testable
T t bl ?
Are the object
serializable ?
The presentation layer can be simply tested and
changed?
Can we display the same data using a platform
other than the webforms?
Where is the separation of concerns?
Presentation – Business Logic
g

WHO’S RESPONSIBLE?
The Coder?
The Developer ?
The Designer?
All of them:
The designer should put clear and clean guidelines!
The coder should follow the guidelines and rules
The d
Th developer should d his work: think before
l h ld do hi k thi k b f
coding.

WHO’S RESPONSIBLE?
Many developers can argue that they are doing a
layered application, but they are writing all the logic in
the code b hi d fil of a f
h d behind file f form. Or Some of
Developers try to separate the business logic and
D l t t t th b i l i d
the data layers.
Everyone h different ideas and experiences
E has diff t id d i
about doing this.
So even when layers have a defined responsibility
its necessary to restrict the way the application is
actually coded. And the only way to do that is
y y y
applying a design that affects the code structure.

BEST CHOICE
MVC Layered Application
1.
1 Guidelines and Rules 1.
1 Developer decides
2. Shared language for 2. Every team member
communicating speaks a language
p g g
3. Easy to maintain 3. Hard to maintain
4. Ambiguous and
4.
4 Easy to understand variant structure
the structure
5. Application is
5.
5 The code depends of dependent of the
the developer skills developer skills and
and opinions opinions

DEMO

Practical
“You should be pragmatic with any pattern,
it's not necessary to be applicable for every situation”
Jaffal Hasan
THANKS FOR LISTENING.
Mail: hjaffal@arabiagis.com
LinkedIn profile: http://www linkedin com/in/jaffal
http://www.linkedin.com/in/jaffal
Blog: www.solutionsarchitecture.wordpress.com