A Blueprint for Success

1
A Blueprint for Success

• Standardizing Enterprise Web
• Application Architecture

Diane Keddie and Andrew Gianni University at
Buffalo
2
Background

• Administrative Computing Services
• 42 employees
• 12 web developers
• Building Perl-based Web applications for eight
  years
• Significant training to develop expertise
• How to improve capacity for development and
  support?

3
Goals

• Standardize development process
• Improve quality of code
• Avoid duplication of effort
• Decrease support costs
• Increase agility of development process

4
How We Did It

• Developed standards and best practices (directory
  structures, naming schemes, coding standards,
  testing)
• Moved reusable code to central repository
• Isolated data, data processing and display
  through implementation of model/view/controller
  (MVC) architecture

5
MVC

• In the MVC paradigm the user input, the modeling
  of the external world, and the visual feedback to
  the user are explicitly separated and handled by
  three types of object, each specialized for its
  task. The view manages the graphical and/or
  textual output to the portion of the bitmapped
  display that is allocated to its application. The
  controller interprets the mouse and keyboard
  inputs from the user, commanding the model and/or
  the view to change as appropriate. Finally, the
  model manages the behavior and data of the
  application domain, responds to requests for
  information about its state (usually from the
  view), and responds to instructions to change
  state (usually from the controller).
• Steve Burbeck, Ph.D.

6
Advantages of MVC

• Ease of distributing development work
• Ease of prototyping
• Ease of testing
• Ease of support
• Same model can be used for various views
• More scalable

7
Disadvantages of MVC

• Complexity
• Higher learning curve
• More files to develop and maintain
• Overcoming the challenge of complexity
• Standard directory structure and naming
  conventions
• Shared Code Repository
• Build project script
• Code Review Process
• Software Engineering Infrastructure Group

8
The View

• The interface layer
• The HTML code, although some would argue the
  browser
• Also the logic to define display and formatting

9
The ViewSeparating Business Logic from
Presentation Logic

• Determine method to use for implementing
• Determine how data will be passed to the view
• Determine where to draw the line drawn between
  business logic and presentation logic?
• Wrapper template

10
The View

• Identify common page types
• Identify common page components
• Create a shared repository for common elements

11
The Model

• The data, usually in the form of a database
• Can also be an interface layer for the database
• We use a combination of the ClassDBI Perl
  module and some home grown code
• MVC line blurs when writing data access and data
  aggregation code

12
The Model in the Enterprise

• Some tables are shared
• Shared code developed to access them (ClassDBI
  and SQL)
• Object Oriented ClassDBI allows for shared code
  through inheritance
• All applications have a database class
  (ProjectDB) which inherit from ACSClassDBI,
  which in turn inherits from ClassDBI

13
The Controller

• Application behavior
• Data validation
• Business rules

14
Web Application Behavior

• Standard application on its head
• User-driven not application driven
• Stateless
• Process data, then render the next page

15
Web Application Behavior
respond
render
16
Web Application Behavior
Enter Name Enter Bio Enter Interest
Submit
respond
render
respond
render
respond
render
respond
render
respond
render
17
Building a Framework
before processing
before respond
respond
after respond
before render
render
after render
after processing
18
Framework Pseudocode
page dispatch() page-gtrespond_enter() next_pa
ge page-gtrespond() page-gtrespond_leave() next
_page-gtrender_enter() next_page-gtrender() next_p
age-gtrender_leave()
19
Framework Code in Perl (CGIPrototype)
self-gtprototype_enter self-gtapp_enter my
this_page self-gtdispatch this_page-gtcontrol
_enter this_page-gtrespond_enter my
next_page this_page-gtrespond
this_page-gtrespond_leave if (this_page ne
next_page) this_page-gtcontrol_leave
next_page-gtcontrol_enter
next_page-gtrender_enter next_page-gtrender
next_page-gtrender_leave next_page-gtcontrol_lea
ve self-gtapp_leave self-gtprototype_leave
20
The Object Oriented Framework

• Allows for code reuse through inheritance
• Page behavior becomes increasingly specific
• Policy changes addressed through changes towards
  top of class hierarchy

21
The Hierarchy

• CGIPrototype - defines general CGI application
  behavior
• CGIPrototypeHidden - defines the behavior of
  a CGI application that uses hidden form fields to
  maintain state
• ACSCGIPrototype - defines departmental
  application behavior, including data validation,
  authorization, hours of availability, data policy
  acceptance

22
The Hierarchy (contd.)

• ProjectApp - defines the general behavior of a
  given application (application specific
  authorization, validation, etc.)
• ProjectApppage - defines behavior specific to
  a given page within an application

23
Data Validation

• Validation of data is a common Web application
  challenge
• Basics
• Format
• Required-ness
• Content
• Advanced
• Business Rules

24
Data Validation

• DataFormValidator Perl module
• Basic validation of form fields is simple
• attributes (required, optional)
• constraints (phone_number, email)
• DataFormValidator facilitates explicit business
  rule implementation
• Business rules are atomic chunks of code
• valid_date_range is just a more complicated
  constraint than phone_number

25
Rapid Prototyping and Development

• Application prototypes developed with HTML that
  will eventually be used in the application, not
  thrown out
• The object oriented framework allows for
  incremental, iterative implementation
• Users can perform acceptance testing at any point
  in the development cycle

26
ePTF Case Study

• Taking personnel transactions online
• Working page prototypes developed within a couple
  of weeks
• Data model developed in parallel with interface
  prototyping
• General application behavior definition begins
  before completion of data model
• Working application, sans business rules within
  six months with five part-time developers
• Explicit business rules allow for backfill later
  without maintenance penalty

27
Questions?

• Andrew Gianni - agianni_at_buffalo.edu
• Diane Keddie - dkeddie_at_buffalo.edu