Download
1 / 29
290 likes | 302 Views
Understand the concept of layers in application design, their advantages, and the common three-layer design. Learn how to incorporate a services layer, design steps for a layered structure, and choose communication protocols effectively.
E N D
LAYERED APPLICATION SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
OVERVIEW • Layers • Difference between layers and tiers • Advantage of layers • The common three layer design • Service layer • Incorporating services layer in an application • Design steps for a layered structure
Layers • The design of an application can be decomposed into logical groupings of software components. These logical groupings are called layers. • Layers help to differentiate between the different kinds of tasks performed by the components, making it easier to create a design that supports reusability of components. • Each logical layer contains a number of discrete component types grouped into sub layers, with each sub layer performing a specific type of task. • Layers are concerned with the logical division of components and they can be located on different tiers, or they may reside on the same tier.
Difference between layers and tiers • Layers describe the logical groupings of the functionality and components in an application whereas • Tiers describe the physical distribution of the functionality and components on separate servers, computers, networks, or remote locations.
Advantages of layers • By identifying the generic types of components that exist in most solutions, you can construct a meaningful map of an application or service, and then use this map as a blueprint for your design. • Dividing an application into separate layers that have distinct roles and functionalities helps you to • maximize maintainability of the code • optimize the way that the application works when deployed in different ways • provides a clear delineation between locations where certain technology or design decisions must be made.
The common three-layer design consists of the following layers : • Presentation layer • Business layer • Data layer
Presentation layer This layer contains the user oriented functionality responsible for managing user interaction with the system, and generally consists of components that provide a common bridge into the core business logic encapsulated in the business layer.
Business layer This layer implements the core functionality of the system, and encapsulates the relevant business logic. It generally consists of components, some of which may expose service interfaces that other callers can use.
Data layer This layer provides access to data hosted within the boundaries of the system, and data exposed by other networked systems; perhaps accessed through services. The data layer exposes generic interfaces that the components in the business layer can consume.
Services Layer • When an application must provide services to other applications, as well as implementing features to support clients directly, a common approach is to use a services layer that exposes the business functionality of the application. • The services layer effectively provides an alternative view that allows clients to use a different channel to access the application.
Incorporating a services layer in an application • In this scenario, users can access the application through the presentation layer, which communicates either directly with the components in the business layer. • Meanwhile, external clients and other systems can access the application and make use of its functionality by communicating with the business layer through service interfaces. This allows the application to better support multiple client types, and promotes re-use and higher level composition of functionality across applications. • In some cases, the presentation layer may communicate with the business layer through the services layer.
Design Steps for a Layered Structure • When starting to design an application, the first task is to focus on the highest level of abstraction and start by grouping functionality into layers. • Next, we must define the public interface for each layer, which depends on the type of application we are designing. • Once we have defined the layers and interfaces, we must determine how the application will be deployed. • Finally, we choose the communication protocols to use for interaction between the layers and tiers of the application.
Design steps Step 1- choose your layering strategy Step 2- determine the layers your require Step 3- decide how to distribute layers and components Step 4- determine if you need to collapse layers Step 5- determine rules for interaction between layers Step 6- identify cross cutting concerns Step 7- define the interfaces between layers Step 8- choose your deployment strategy Step 9- choose communication protocols
Step 1 – Choose your layering strategy • Using a layered approach can improve the maintainability of the application and make it easier to scale out when necessary to improve performance. • Determining the granularity of layering appropriate for the application is a critical first step in determining your layering strategy. • Also consider whether you are implementing layering in order to achieve purely logical separation of functionality, or in order to potentially achieve physical separation as well.
Determining which of your application layers are likely to be deployed to separate tiers, and which are likely to be deployed to the same tier, is also an important part of your layering strategy. • To maintain flexibility, always ensure that interaction between layers is loosely coupled. • Carefully considering how your application is layered, and how the layers will interact with each other, will ensure a good balance between performance and flexibility.
Step 2 – Determine the layers you require • There are many different ways to group related functionality into layers. • The most common approach in business applications is to separate presentation, services, business, and data access functionality into separate layers. • Be careful when adding additional layers, and do not add them if they do not provide a logical grouping of related components that manifestly increases the maintainability, scalability, or flexibility of your application.
Step 3 – Decide how to distribute layers and components • You should distribute layers and components across separate physical tiers only where this is necessary. • Common reasons for implementing distributed deployment include security policies, physical constraints, shared business logic, and scalability.
Example: • In Web applications, if your presentation components access your business components synchronously, consider deploying the business layer and presentation layer components on the same physical tier to maximize performance and ease operational management, unless security restrictions require a trust boundary between them.
Step 4 – Determine if you need to collapse layers • In some cases, it makes sense to collapse or relax layers. • For example, an application with very limited business rules, might implement both the business and presentation logic in a single layer. • However, the general rule is that you should always group functionality into layers. In some cases, one layer may act as a proxy or pass-through layer that provides encapsulation and loose coupling without providing a great deal of functionality. However, by separating that functionality, you can extend it later with little or no impact on other layers in the design.
Step 5 – Determine rules for interaction between layers • The main reasons for specifying interaction rules are to minimize dependencies and eliminate circular references. • For example, if two layers each have a dependency on components in the other layer you have introduced a circular dependency. As a result, a common rule to follow is to allow only one way interaction between the layers using one of the following approaches:
Top-down interaction: Higher level layers can interact with layers below, but a lower level layer should never interact with layers above. This rule will help you to avoid circular dependencies between layers. Strict interaction: Each layer must interact with only the layer directly below. This rule will enforce strict separation of concerns where each layer knows only about the layer directly below. The benefit of this rule is that modifications to the interface of the layer will only affect the layer directly above. Loose interaction: Higher level layers can bypass layers to interact with lower level layers directly. This can improve performance, but will also increase dependencies. In other words, modification to a lower level layer can affect multiple layers above.
Step 6 – Identify cross cutting concerns • After you define the layers, you must identify the functionality that spans layers. This functionality is often described as crosscutting concerns, and includes logging, caching, validation, authentication, and exception management. • It is important to identify each of the crosscutting concerns in your application, and design separate components to manage these concerns where possible. • This approach helps you to achieve of better reusability and maintainability. • Avoid mixing the crosscutting code with code in the components of each layer, so that the layers and their components only make calls to the crosscutting components when they must carry out an action such as logging, caching, or authentication. • As the functionality must be available across layers, you must deploy crosscutting components in such a way that they are accessible to all the layers—even when the layers are located on separate physical tiers. • There are different approaches to handling crosscutting functionality, from common libraries such as the patterns & practices Enterprise Library to Aspect Oriented Programming (AOP) methods.
Step 7 – Define the interfaces between layers • When you define the interface for a layer, the primary goal is to enforce loose coupling between layers. What this means is that a layer should not expose internal details on which another layer could depend. Instead, the interface to a layer should be designed to minimize dependencies by providing a public interface that hides details of the components within the layer. This hiding is called abstraction, and there are many different ways to implement it.
The following design approaches can be used to define the interface to a layer: • Abstract interface • Common design type • Dependency inversion • Message-based
Step 8 – Choose your deployment strategy • There are several common patterns that represent application deployment structures found in most solutions. When it comes to determining the best deployment solution for your application, it helps to first identify the common patterns. Once you have a good understanding of the different patterns, you then consider scenarios, requirements, and security constraints to choose the most appropriate pattern or patterns.
Step 9 – Choose communication protocols • The physical protocols used for communication across layers or tiers in your design play a major role in the performance, security, and reliability of the application. • The choice of communication protocol is even more important when considering distributed deployment. • When components are located on the same physical tier, you can often rely on direct communication between these components. • However, if you deploy components and layers on physically separate servers and client machines you must consider how the components in these layers will communicate with each other efficiently and reliably.
