Application Architecture Plan: Layers

Layers

Chapter 9: Layers and Tiers

Layers

Layers are the logical groupings of the software components that make up the application or service.

Presentation, Business, and Data Services

• Presentation services. These are the user-oriented services responsible for managing user interaction with the system, and generally consist of components located within the presentation layer. They provide a common bridge into the core business logic encapsulated in the business services.
• Business services. These services implement the core functionality of the system, and encapsulate the relevant business logic. They generally consist of components located within the business layer, which may expose service interfaces that other callers can use.
• Data services. These services provide access to data that is hosted within the boundaries of the system, and data exposed by other back-end systems; perhaps accessed through services. The data layer exposes data to the business layer through generic interfaces designed to be convenient for use by business services

Components

Each layer of an application will contain a series of components that implement the functionality for that layer.

Presentation Layer Components

Presentation layer components implement the functionality required to allow users to interact with the application. The following types of components are commonly found in the presentation layer:
• User interface (UI) components. These components provide the mechanism for users to interact with the application. They format data and render it for display, and acquire and validate data entered by users.
• UI process components. To help synchronize and orchestrate user interactions, it can be useful to drive the process using separate UI process components. This prevents the process flow and state management logic from being hard-coded into the UI elements themselves, and allows you to reuse the same basic user interaction patterns in other user interfaces.

Business Layer Components

• Application façade. This is an optional feature that you can use to combine multiple business operations into single messaged-based operations. This feature is useful when you locate the presentation layer components on a separate physical tier from the business layer components, allowing you to optimize use of the communication method that connects them.
• Business components. These components implement the business logic of the application. Regardless of whether a business process consists of a single step or an orchestrated workflow, your application is likely to require components that implement business rules
  and perform business tasks.
• Business workflows. After the UI components collect the required data from the user and pass it to the business layer, the application can use this data to perform a business process. Many business processes involve multiple steps that must be performed in the correct order, and may interact with each other through an orchestration. Business workflow
  components define and coordinate long-running, multi-step business processes, and can be implemented using business process management tools.
• Business entity components. Business entities are used to pass data between components. The data represents real-world business entities, such as products or orders. The business entities that the application uses internally are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be
  implemented using custom object-oriented classes that represent the real-world entities that your application will handle.

Data Layer Components

• Data access components. These components abstract the logic required to access the underlying data stores. Doing so centralizes data access functionality and makes the application easier to configure and maintain.
  • Data helper and utility components. Most data access tasks require common logic that can be extracted and implemented in separate reusable helper components. This helps to reduce the complexity of the data access components and centralizes the logic, which simplifies maintenance. Other tasks that are common across data layer components, and not specific to any set of components, may be implemented as separate utility components.
  Both helper and utility components can often be reused in other applications.
  • Service agents. When a business component must use functionality provided by an external service, you might need to implement code to manage the semantics of communicating with that particular service. Service agents isolate the idiosyncrasies of calling diverse services from your application, and can provide additional services such as basic mapping
  between the format of the data exposed by the service and the format your application requires.

Cross-Cutting Components

• Components for implementing security. These may include components that perform authentication, authorization, and validation.
• Components for implementing operational management tasks. These may include components that implement exception handling policies, logging, performance counters, configuration, and tracing.
• Components for implementing communication. These may include components that communicate with other services and applications.

Services and Layers

• Service interfaces. Services expose a service interface to which all inbound messages are sent. The definition of the set of messages that must be exchanged with a service in order for the service to perform a specific business task constitutes a contract. You can think of a service interface as a façade that exposes the business logic implemented in the service to potential consumers.
  • Message types. When exchanging data across the service layer, data structures are wrapped by message structures that support different types of operations. For example, you might have a Command message, a Document message, or another type of message. These message types are the “message contracts” for communication between service consumers and providers.

Choose layers for application
• If your application does not expose a UI, such as a service application, you do not require a presentation layer.
• If your application does not contain business logic, you may not require a business layer.
• If your application does not expose services, you do not require a services layer.
• If your application does not access data, you do not require a data layer.
• Only distribute components where this is necessary. Common reasons for implementing distributed deployment include security policies, physical constraints, shared business logic, and scalability.
• In Web applications, deploy business components that are used synchronously by user interfaces or user process components in the same physical tier as the user interface to maximize performance and ease operational management, unless there are security implications that require a trust boundary between them.
• In rich client applications where the UI processing occurs on the desktop, you may prefer to deploy components that are used synchronously by UIs or user process components in a separate business tier for security reasons, and to ease operational management.
• Deploy service agent components on the same tier as the code that calls the components, unless there are security implications that require a trust boundary between them.
• Deploy asynchronous business components, workflow components, and business services on a separate physical tier where possible.
• Deploy business entities on the same physical tier as the code that uses them.

Tiers

Consider the client/server or two-tier pattern if:
• You are developing a client that must access an application server.
• You are developing a stand-alone client that accesses an external database.
Consider the three-tier pattern if:
• You are developing an intranet-based application, where all servers are located within a private network.
• You are developing an Internet-based application, and security requirements do not restrict implementation of business logic on the public-facing Web or application server.
Consider the N-tier pattern if:
• Security requirements dictate that business logic cannot be deployed to the perimeter network.
• You have application code that makes heavy use of resources on the server, and you want to offload that functionality to another server.

Chapter 10: Presentation Layer Guidelines (p. 161)

Presentation Layer Components

• User interface (UI) components. User interface components provide a way for users to interact with the application. They render and format data for users. They also acquire and validate data input by the user.
• User process components. User process components synchronize and orchestrate user interactions. Separate user process components may be useful if you have a complicated UI. Implementing common user interaction patterns as separate user process components allows you to reuse them in multiple UIs.

Approach

1. Identify your client type. Choose a client type that satisfies your requirements and adheres to the infrastructure and deployment constraints of your organization. For instance, if your users are on mobile devices and will be intermittently connected to the network, a mobile rich client is probably your best choice.
   2. Determine how you will present data. Choose the data format for your presentation layer and decide how you will present the data in your UI.
   3. Determine your data-validation strategy. Use data-validation techniques to protect your system from untrusted input.
   4. Determine your business logic strategy. Factor out your business logic to decouple it from your presentation layer code.
   5. Determine your strategy for communication with other layers. If your application has multiple layers, such as a data access layer and a business layer, determine a strategy for communication between your presentation layer and other layers.

Design Considerations

• Choose the appropriate UI technology. Determine if you will implement a rich (smart) client, a Web client, or a rich Internet application (RIA). Base your decision on application requirements, and on organizational and infrastructure constraints.
• Use the relevant patterns. Review the presentation layer patterns for proven solutions to common presentation problems.
• Design for separation of concerns. Use dedicated UI components that focus on rendering and display. Use dedicated presentation entities to manage the data required to present your views. Use dedicated UI process components to manage the processing of user interaction.
• Consider human interface guidelines. Review your organization’s guidelines for UI design
• Review established UI guidelines based on the client type and technologies that you have chosen.
• Adhere to user-driven design principles. Before designing your presentation layer, understand your customer. Use surveys, usability studies, and interviews to determine the best presentation design to meet your customer’s requirements

Presentation Layer Frame

Caching
• Caching volatile data.
• Caching unencrypted sensitive data.
• Incorrect choice of caching store.
• Failing to choose a suitable caching mechanism for use in a
Web farm.
• Assuming that data will still be available in the cache — it may
have expired and been removed.

Composition
• Failing to consider use of patterns and libraries that support
dynamic layout and injection of views and presentation at
runtime.
• Using presentation components that have dependencies on
support classes and services instead of considering patterns
that support run-time dependency injection.
• Failing to use the Publish/Subscribe pattern to support
events between components.
• Failing to properly decouple the application as separate
modules that can be added easily.

Exception Management
• Failing to catch unhandled exceptions.
• Failing to clean up resources and state after an exception
occurs.
• Revealing sensitive information to the end user.
• Using exceptions to control application flow.
• Catching exceptions you do not handle.
• Using custom exceptions when not necessary.

Input
• Failing to design for intuitive use, or implementing overly
complex interfaces.
• Failing to design for accessibility.
• Failing to design for different screen sizes and resolutions.
• Failing to design for different device and input types, such as
mobile devices, touch-screen, and pen and ink–enabled
devices.

Layout
• Using an inappropriate layout style for Web pages.
• Implementing an overly complex layout.
• Failing to choose appropriate layout components and
technologies.
• Failing to adhere to accessibility and usability guidelines and
standards.
• Implementing an inappropriate workflow interface.
• Failing to support localization and globalization.

Navigation
• Inconsistent navigation.
• Duplication of logic to handle navigation events.
• Using hard-coded navigation.
• Failing to manage state with wizard navigation.

Presentation Entities
• Defining entities that are not necessary.
• Failing to implement serialization when necessary.

Request Processing
• Blocking the UI during long-running requests.
• Mixing processing and rendering logic.
• Choosing an inappropriate request-handling pattern

User Experience
• Displaying unhelpful error messages.
• Lack of responsiveness.
• Overly complex user interfaces.
• Lack of user personalization.
• Lack of user empowerment.
• Designing inefficient user interfaces.

UI Components
• Creating custom components that are not necessary.
• Failing to maintain state in the Model-View-Controller (MVC)
pattern.
• Choosing inappropriate UI components.

UI Process Components
• Implementing UI process components when not necessary.
• Implementing the wrong design patterns.
• Mixing business logic with UI process logic.
• Mixing rendering logic with UI process logic.

Validation
• Failing to validate all input.
• Failure to validate on the server for security concerns.
• Failing to correctly handle validation errors.
• Not identifying business rules that are appropriate for validation.
• Failing to log validation failures.

Chapter 11: Business Layer Guidelines

1. Create an overall design for your business layer:
   o Identify the consumers of your business layer.
   o Determine how you will expose your business layer.
   o Determine the security requirements for your business layer.
   o Determine the validation requirements and strategy for your business layer.
   o Determine the caching strategy for your business layer.
   o Determine the exception-management strategy for your business layer.
2. Design your business components:
   o Identify business components your application will use.
   o Make key decisions about location, coupling, and interactions for business
   components.
   o Choose appropriate transaction support.
   o Identify how your business rules are handled.o Identify patterns that fit the requirements.
3. Design your business entity components:
   o Identify common data formats for the business entities.
   o Choose the data format.
   o Optionally, choose a design for your custom objects.
   o Optionally, determine how you will serialize the components.
4. Design your workflow components:
   o Identify workflow style using scenarios.
   o Choose an authoring mode.
   o Determine how rules will be handled.
   o Choose a workflow solution.
   o Design business components to support workflow.

Business Layer Frame

Authentication
Applying authentication in a business layer when not required. Designing a custom authentication mechanism. Failing to use single-sign-on where appropriate.
Authorization
Using incorrect granularity for roles. Using impersonation and delegation when not required. Mixing authorization code and business processing code.
Business Components
Overloading business components, by mixing unrelated
functionality. Mixing data access logic within business logic in business
components. Not considering the use of message-based interfaces to
expose business components.
Business Entities
Using the Domain Model when not appropriate. Choosing incorrect data formats for your business entities. Not considering serialization requirements.
Caching
Caching volatile data. Caching too much data in the business layer. Failing to cache data in a ready-to-use format. Caching sensitive data in unencrypted form.
Coupling and Cohesion
Tight coupling across layers. No clear separation of concerns within the business layer. Failing to use a message-based interface between layers.
Concurrency and Transactions
Not preventing concurrent access to static data that is not read-only. Not choosing the correct data concurrency model. Using long-running transactions that hold locks on data.
Data Access
Accessing the database directly from the business layer. Mixing data access logic within business logic in business components.
Exception Management
Revealing sensitive information to the end user. Using exceptions to control application flow. Not logging sufficient detail from exceptions. Failing to appropriately notify users with useful error messages.
Logging and Instrumentation
Failing to add adequate instrumentation to business components. Failing to log system-critical and business-critical events. Not suppressing logging failures.
Service Interface
Breaking the service interface. Implementing business rules in the service interface. Failing to consider interoperability requirements.
Validation
Relying on validation that occurs in the presentation
layer. Failure to validate for length, range, format and type. Not reusing the validation logic.
Workflows
Not considering application management requirements. Choosing an incorrect workflow pattern. Not considering how to handle all exception states. Choosing an incorrect workflow technology.

Chapter 12: Data Access Layer Guidelines

• Data access logic components. Data access components abstract the logic necessary to access your underlying data stores. Doing so centralizes the data access functionality, which makes the application easier to configure and maintain.
• Data helpers / utilities. Helper functions and utilities assist in data manipulation, data transformation, and data access within the layer. They consist of specialized libraries and/or custom routines especially designed to maximize data access performance and reduce the development requirements of the logic components and the service agent parts of the
  layer.
• Service agents. When a business component must use functionality exposed by an external service, you might need to create code that manages the semantics of communicating with that service. Service agents isolate your application from the idiosyncrasies of calling diverse
  services, and can provide additional services such as basic mapping between the format of the data exposed by the service and the format your application requires.

Approach

1. Create an overall design for your data access layer:
   a. Identify your data source requirements.
   b. Determine your data access approach.
   c. Choose how to map data structures to the data source.
   d. Determine how to connect to the data source.
   e. Determine strategies for handling data source errors.
2. Design your data access components:
   a. Enumerate the data sources that you will access.
   b. Decide on the method of access for each data source.
   c. Determine whether helper components are required or desirable to simplify data access component development and maintenance.
   d. Determine relevant design patterns. For example, consider using the Table Data Gateway, Query Object, Repository, and other patterns.
3. Design your data helper components:
   a. Identify functionality that could be moved out of the data access components and centralized for reuse.
   b. Research available helper component libraries.
   c. Consider custom helper components for common problems such as connection strings, data source authentication, monitoring, and exception processing.
   d. Consider implementing routines for data access monitoring and testing in your helper components.
   e. Consider the setup and implementation of logging for your helper components.
4. Design your service agents:
   a. Use the appropriate tool to add a service reference. This will generate a proxy and the data classes that represent the data contract from the service.
   b. Determine how the service will be used in your application. For most applications, you should use an abstraction layer between the business layer and the data access layer, which will provide a consistent interface regardless of the data source. For smaller applications, the business layer, or even the presentation layer, may access the service agent directly.

Chapter 13: Service Layer Guidelines

• Service interfaces. Services expose a service interface to which all inbound messages are sent. The definition of the set of messages that must be exchanged with a service, in order for the service to perform a specific business task, constitutes a contract. You can think of a service interface as a façade that exposes the business logic implemented in the service to
  potential consumers.
  • Message types. When exchanging data across the service layer, data structures are wrapped by message structures that support different types of operations. For example, you might have a Command message, a Document message, or another type of message. These message types are the “message contracts” for communication between service consumers and providers.

Approach

• Define the Data and Message contracts that represent the schema used for messages.
• Define the Service contracts that represent operations supported by your service.
• Define the Fault contracts that return error information to consumers of the service.
• Design transformation objects that translate between business entities and data contracts.
• Design the abstraction approach used to interact with the business layer.