Layered Architectures

1. 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

2. 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

3. 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

4. Data Management Logic Presentation Logic Application Logic 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.

5. 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 Application Logic Data Management Logic Input Validation Transaction Processing Persistence Management Data Access Gui Controllers Gui Security Business Rules Auditing System Log User Management

6. 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?

7. 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

8. 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.

9. Layer Example User clicks employee name in employee list diplayEmployeeInfo(id = 5) EmployeeList getEmployee(id = 5) getObject("Employee", id=5) EmployeeList Listener <<controller>> executeSQL() EmployeeManager <<controller>> TableManager <<controller>> DBController <<controller>> resultSet displayEmployee Employee Info generateSql(id=5) buildEmployeeObject(resultSet) EmployeeTableSqlGenerator EmployeeBuilder

10. 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)

11. 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) Database Connectivity Layer Manage connections to database possibly connection pool insert select update delete getObject() storeObject() This layer only ever deals with Objects. NO SQL This layer maps between the object world and the relational DB world This layer manages data