Layered Architectures

Download Report

Transcript Layered Architectures

Layered Architectures
The objectives of this chapter are:
To understand the principles and importance of Layered
Architectures
To explain the structure of application development in Java
Cohesion
You may have realized that Cohesion is one of the most
important aspects of Object Oriented Software Development
Classes have few, well defined responsibilities
Each class's responsibilities should be logically related
When classes are developed in this manner, the complexity of
a system shifts from the classes to the communication
between objects
Classes are not complex
How objects communicate becomes more complex so it must be
managed
Managing communication between objects now becomes an
added responsibility for the system
Understanding the communication between discrete components is
defined as architecture
Many design patterns specifically address these types of problems
Architecture
Unfortunately, calling oneself a "Software Architect" is a new
"in" term.
Many people call themselves software architects, but do not develop
architectures
Architectures must be defined early within the development process;
however, they must remain flexible.
The initial architecture is almost always wrong, if it cannot be adjusted,
the project will fail.
Early architectures can be regarded as "rough cuts". They aren't correct,
but they drive the process forward.
Most successful architectures are based upon a layered
approach
The Gartner 3-layer model is a good starting point
Layers are logical
Each layer has a defined purpose
The communication between layers is well-defined
The Gartner 3-layer Model -Revisited
The Gartner group has identified 3 types of logic which exist
within the typical business application
Presentation: How is data presented to the User
Application: How is data processed
Data Management: How is data stored and retrieved
In order to have flexibility between the layers, the layers must
be loosely coupled rather than tightly coupled.
Presentation
Logic
Application
Logic
Data Management
Logic
N-Tier
It is important to remember that each layer is logical
"Presentation" is a high level layer
The presentation layer can be composed of many sub-layers, each of
which having a lower level of abstraction
Breaking down high level layers into logical sub layers is the
essence of N-Tier architecture:
Presentation
Logic
Gui
Gui
Controllers
Application
Logic
Input
Validation
Security
User
Management
Transaction
Processing
Business
Rules
Data Management
Logic
Persistence
Management
Data
Access
Auditing
System Log
Communication between Layers (Tiers)
The previous slide shows that architectures can have high
level components and low level components.
Architecture is always higher level than code
As one goes deeper into the architecture, one will eventually identify
objects.
In order for this approach to work, the communication between
each layer must be defined.
One must define how the communication is to occur
Are the layers deployable within an Intranet?
Are the layers deployable across the Internet?
One must define what is to be communicated (each layer must have an
interface)
Which layers are coupled?
What are the functional requirements of a layer?
What messages are sent between layers?
Cohesion and Coupling issues
Many people remember the old days of spaghetti code
Subroutine calls from everywhere, to everywhere
This is a symptom of focusing ones attention at a very low level of
abstraction
This happens when one is focused on the code and not the design
Unfortunately, it is possible to create spaghetti objects
Every object communicates with every other object
Coupling is too high
•
If the domain model contains cohesive objects, coupling is
likely to remain low.
Hint: keep your objects cohesive
If the communication between layers is defined at the high
level, the coupling between layers is likely to remain low
Hint: define communication between layers at a high level of abstraction
Implementing Layer Communication
If the communication between layers is defined at the high
level, the implementation should follow suit.
Objects communicate through messages.
There should be messages (methods) which match the high level
definitions of the interface
But how do we map high level messages into low level actions?
Controller objects fulfil this purpose.
Controller objects have a high level interface
Controller objects don't actually do the work to fulfil the interface
Controller objects delegate the responsibility of fulfilling a request to other
objects
Controllers coordinate other objects
•
Each layer will have one or more controller objects
•
The interface for the layer is defined by the interface implemented by the
layer's controller objects.
Layer Example
EmployeeList
User clicks employee name
in employee list
diplayEmployeeInfo(id = 5)
EmployeeList
Listener
<<controller>>
getEmployee(id = 5)
getObject("Employee", id=5)
Employee
Manager
<<controller>>
displayEmployee
Table
Manager
<<controller>>
executeSQL()
resultSet
DBController
<<controller>>
Employee Info
generateSql(id=5)
EmployeeTable
SqlGenerator
buildEmployeeObject(resultSet)
EmployeeBuilder
Dealing with Object Persistence
When an application executes, objects are stored in memory
When the application terminates, those objects disappear
Most business entities require persistence
They must be accessible upon successive executions of the application
Object persistence could be implemented using object
serialization
Many businesses have invested large amounts of money in
relational (sql) databases
It is possible to put objects into a database
The data within a class model is often equivalent to a 3rd normal form
data model (inheritance must be addressed)
Object Persistence: Layers
Application Layer
Process Employee Objects
Data Access Layer
Map Objects to Relational DB
(generate SQL)
Map Relational Tables to Objects
(generate SQL)
getObject()
storeObject()
This layer only ever deals with
Objects. NO SQL
This layer maps between the object
world and the relational DB world
Database Connectivity Layer
Manage connections to database
possibly connection pool
insert
select
update
delete
This layer manages data