Architectural Patterns Support Lecture

Software Architecture l Architecture is OVERLOADED System architecture Application architecture l Architecture for this presentation is l The modules, processes, interconnections, and protocols which constitute the deployed software system. l Different from the behavioral architecture which describes how the business classes execute the business processes.

Architecture Specification l Document which defines in text and diagrams the design, flow and technologies of the design. l Shows how persistence, communication, and behavior are to be implemented in the system.

Architectural Layers - Patterns Presentation interactions with the user – HTML, thick client, MVC, web services Domain (Logic) Business rules, validations, calculations, verifications Data Storage database Environmental Session management, messaging

Presentation Architectural Patterns l Presentation interactions with the user l No Client l Thick Client (rich client) l Thin Client

Presentation Architectural Patterns l Model View Controller l Application Controller l Input Controller Page Controller Front Controller l View Controller Template View Transform View Two Step View

Model View Controller Separation of Presentation (View/Controller) from Domain (Model) Separation of View and Controller Model – Domain object View – Presentation object Controller – Controller object to handle user request/response

Application Controller A centralized point for handling screen navigation and flow of an application. Application Controller – determines which type of input is needed or which screen. Input Controller View Application Controller Domain Layer

Application Controller

l A single point of control to change program flow and navigation l May be in mediating layer between the presentation and the domain l May be reusable across various presentations l Testable outside the UI framework.

Front Controller

Page Controller

Front vs Page Controller l Front Controller Single point for adding behavior Can add behavior dynamically (filter pattern) Use with more complex applications l Page Controller Simple - Input controller per page Don’t put controller logic into scriplets – use separate classes More prone to duplicate code with this controller

Template View

Transform View

Example

Data Storage l Need mechanisms to allow RDBMS to communicate in the OO world. l With OO databases none of these patterns necessary. l Useful even if non-OO language wants to communicate with RDBMS to make the DB flexible to change in type and to make the data representation protected.

Data Storage Patterns l Table Data Gateway l Row Data Gateway l Active Record l Data Mapper l Structural Patterns Foreign Key Mapping, Identify Field Association, Table Mapping, Single Table Inheritance.

Table Data Gateway

Row Data Gateway

Row Data Gateway (2)

Active Record

Data Mapper

Distribution Patterns l Remote Façade l Data Transfer Object

Remote Facade

Data Transfer Object

Summary l No one patterns is an end all l Patterns are mechanisms to help decompose applications into reusable, maintainable, modules. l The layers of development help to define the needed patterns l No pattern is always correct -- fit the application.