Upload
minda
View
49
Download
0
Tags:
Embed Size (px)
DESCRIPTION
A Blueprint for Success. Standardizing Enterprise Web Application Architecture. Diane Keddie and Andrew Gianni University at Buffalo. Background. Administrative Computing Services 42 employees 12 web developers Building Perl-based Web applications for eight years - PowerPoint PPT Presentation
Citation preview
A Blueprint for SuccessStandardizing Enterprise Web
Application Architecture
Diane Keddie and Andrew GianniUniversity at Buffalo
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?
Goals
• Standardize development process• Improve quality of code• Avoid duplication of effort• Decrease support costs• Increase agility of development process
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
MVCIn 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.
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
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
The View
• The interface layer• The HTML code, although some would argue the
browser• Also the logic to define display and formatting
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
The View
Identify common page types
Identify common page components
Create a shared repository for common elements
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 Class::DBI Perl
module and some home grown code• MVC line blurs when writing data access and
data aggregation code
The Model in the Enterprise
• Some tables are shared• Shared code developed to access them
(Class::DBI and SQL)• Object Oriented Class::DBI allows for shared
code through inheritance• All applications have a database class
(Project::DB) which inherit from ACS::ClassDBI, which in turn inherits from Class::DBI
The Controller
• Application behavior• Data validation• Business rules
Web Application Behavior
• Standard application on it’s head• User-driven not application driven• Stateless• Process data, then render the next page
Web Application Behavior
respond
render
Web Application Behavior
respond
render
Enter Name Enter Bio Enter Interest Submit
respond render
respond
render
respond render
respondrender
Building a Framework
before processing
before respond
respond
after respond
before render
render
after render
after processing
Framework Pseudocode$page = dispatch()$page->respond_enter()$next_page = $page->respond()$page->respond_leave()$next_page->render_enter()$next_page->render()$next_page->render_leave()
Framework Code in Perl (CGI::Prototype) $self->prototype_enter; $self->app_enter; my $this_page = $self->dispatch; $this_page->control_enter; $this_page->respond_enter; my $next_page = $this_page->respond; $this_page->respond_leave; if ($this_page ne $next_page) { $this_page->control_leave; $next_page->control_enter; } $next_page->render_enter; $next_page->render; $next_page->render_leave; $next_page->control_leave; $self->app_leave; $self->prototype_leave;
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
The Hierarchy
CGI::Prototype - defines general CGI application behavior
CGI::Prototype::Hidden - defines the behavior of a CGI application that uses hidden form fields to maintain state
ACS::CGIPrototype - defines departmental application behavior, including data validation, authorization, hours of availability, data policy acceptance
The Hierarchy (contd.)
Project::App - defines the general behavior of a given application (application specific authorization, validation, etc.)
Project::App::page - defines behavior specific to a given page within an application
Data Validation
• Validation of data is a common Web application challenge
• Basics• Format• Required-ness• Content
• Advanced• Business Rules
Data Validation
• Data::FormValidator Perl module• Basic validation of form fields is simple
• attributes (required, optional)• constraints (phone_number, email)
• Data::FormValidator facilitates explicit business rule implementation• Business rules are atomic chunks of code• valid_date_range is just a more complicated
constraint than phone_number
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
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