Pro .NET 2.0 Code And Design Standards In CSharp (2006) [eng]

126 C H A P T E R 6 ■ D E S I G N S T R U C T U R E

Figure 6-1. Design context

The Standard: Design Context

The standard acknowledges that the design workspace has to be identified, so that appropriate resources may be organized. In practice, not all of the functionality of an enterprise may be included within an enterprise context.

C H A P T E R 6 ■ D E S I G N S T R U C T U R E

127

Enterprise Design Framework

While the design context defines the workspace, it is the framework that transposes the concept of architecture into concrete layers (e.g., application or enterprise services layer) in which to design a composition of interrelated modules of functionality.

■Note The tiers or layers of the enterprise framework may follow industry best practices, which, for example, are articulated in the Open Groups’ Architecture Framework (TOGAF 8.1 Enterprise Edition). TOGAF derives from TAFIM, an architecture framework developed by the U.S. Department of Defense. You can review TOGAF at www.opengroup.org/architecture.

What

An enterprise design framework is a blueprint that defines the structures or layers of an enterprise. The structures or layers map conceptually, although not always physically, to a given architecture.

Where

The enterprise design framework is used where there are many structures that need to be blended or unified into a systematic whole.

Why

Enterprise design embodies purpose and discipline, so it requires a framework on which to guide it to that end.

■Note The design framework is itself a design that evolves from a synthesis of community ideas and practices. Once an idea or practice becomes accepted, then it is inevitable that it will find favor in a design policy.

How

The framework is mapped to layers or tiers of functionality. For practical purposes, the deployment architecture is shown conceptually, although it is a concrete layer on which all other concrete layers are deployed. The enterprise architecture remains a concept that acts as the outer boundary of the framework. Figure 6-2 illustrates an enterprise design framework. Note that it shows the mapping of respective architectures to layers (except for the deployment). The framework is implemented in various summarized forms, where typically reference is limited to layers or tiers of “architecture” that exclude reference to the surrounding architectures (e.g., deployment and enterprise); the framework is commonly summarized as an “n-tier” architecture.

128 C H A P T E R 6 ■ D E S I G N S T R U C T U R E

Figure 6-2. Enterprise design framework

The Standard: Enterprise Design Framework

The standard acknowledges the use of an enterprise design framework where there are many structures that need to be managed as a cohesive composite.

Application Layer

An application layer represents the software functionality of an enterprise. It may comprise in-house and outsourced functionality that is seamlessly presented to a user.

What

The application layer is a conceptual repository of applications that may be deployed across many networks and accessible locally, regionally, or globally. For example, a Web application would reside in the application layer, and it may through an application services layer con-

ise services layer.

C H A P T E R 6 ■ D E S I G N S T R U C T U R E

129

Where

The application layer resides in an enterprise framework and leverages an integration layer to access enterprises services (or platform services).

Why

The design, development, and maintenance of software is a specialized skill with its own set of dynamics. Encapsulating software into a layer is an efficient and convenient way to manage the special needs of application development.

How

An application layer is built up as a composite of domain applications. Application integration and common functionality are abstracted into application integration and enterprise services layers, respectively. That has several benefits: it maximizes decoupling, minimizes the effect of change, and minimizes development in a domain application.

The Standard: Application Layer

The standard acknowledges that the design, development, and maintenance of software is a specialized skill with its own set of dynamics. Encapsulating domain software into a layer is an efficient and convenient way to manage the special needs of application development.

Application Design Types

Essentially, there are three application design types: domain, enterprise, and services. The different application design types complement the nature of the business, which is classified as domain and enterprise. A domain dynamic is functionality that originates from within the organization and is custom to a given domain, whereas an enterprise dynamic is common throughout an industry, or common throughout industry generally. While it is obvious what constitutes a services application, the same cannot be said about a domain or enterprise application. The following tip illustrates what constitutes “enterprise applications.”

■Tip Martin Fowler gives some good examples of what he considers to be “enterprise applications,” including payroll, accounting, and customer service applications. He considers that the following types of applications are not “enterprise applications”: automobile fuel injection, operating systems, compilers, and games. Refer to Martin Fowler, Patterns of Enterprise Application Architecture (Addison-Wesley, 2003), p. 3.

Domain Application

Organizations and their departments require applications to manage domain-specific func-

130 C H A P T E R 6 ■ D E S I G N S T R U C T U R E

What

A domain application is an application that fulfills the custom requirements of a given domain (e.g., an organization or department or activity). For example, a domain application may be one developed in-house to meet the requirements of the assembly line domain, or it may be a new game for the domain of game enthusiasts.

Where

A domain application resides within the enterprise framework, in the application layer. (Note this refers to a domain within an organization rather than an activity domain, such as game domain.)

Why

Domain applications cater to requirements that are not universal and fulfill domain requirements.

How

Domain applications are developed according to requirements that are not universal; in other words, they are quite specific to a given domain. For example, Model T production managers have a domain requirement for an application that monitors production efficiently at each stage of their mass-production assembly lines.

■Note A domain application can cross over and become an enterprise application if the functionality becomes universal.

The Standard: Domain Application

The standard acknowledges the design and development of domain applications to service the custom or non-universal requirements of a domain.

Enterprise Application

While organizations are different in many respects, they are similar in other respects: an enterprise application fulfills common industry or multiple industry standard requirements.

What

An enterprise application is an application that encapsulates functionality common or standard to an industry type or industry in general (e.g., a payroll application).

Where

An enterprise application resides within the enterprise framework in the application layer.

C H A P T E R 6 ■ D E S I G N S T R U C T U R E

131

Why

A significant part of an organization’s functionality is routine and without a domain imperative. In such a circumstance, it is often preferable to adopt a successful industry application than to develop the functionality as a “domain” application by “reinventing the wheel.”

How

Generally, an enterprise application is developed by a vendor to meet industry or multiindustry requirements. They are commonly developed as Web or Windows application types, which follow a three-tier or five-tier design architecture (refer to the section “Application Design Architectures” later in this chapter). Examples of an enterprise application include payroll or accounting applications.

The Standard: Enterprise Application

The standard acknowledges the use of enterprise applications to provide functionality that is routine or universal and is without a domain imperative.

Services Application

A feature of an enterprise framework is the abstraction of common functionality into a published service (e.g., user authentication or application integration services).

What

A services application is an application that publishes functionality or services that is made available to other applications or services.

Where

A service application is commonly found in an application integration layer, enterprise services layer (or platform), network services layer, or communications integration layer.

Why

Encapsulating functionality as services to distribute throughout an enterprise is an effective and efficient way to manage functionality.

How

Functionality is encapsulated into assemblies and deployed as published services located on a server (LAN, WAN, or Web server).

The Standard: Services Application

The standard acknowledges the use of services applications to distribute functionality across an enterprise as an effective and efficient way to manage functionality.

132 C H A P T E R 6 ■ D E S I G N S T R U C T U R E

Application Design Architectures

In this section, we discuss application design architecture and examine the following: two-tier, three-tier, five-tier, and enterprise architectures. Is one design architecture better than the other? While there is much debate, the more relevant issue is when is one design architecture more appropriate than another. The essence of good design is to match the most appropriate solution to the requirements. Thus, on a site, much can be gained by using a range of design architectures, rather than shoe-horning all applications into one architecture type. For example, in a given situation, it may be inappropriate to be conservative and use a three-tier architecture when a more expensive five-tier architecture has a lower total cost of ownership. On the other hand, unnecessary cost and overhead may result from developing functionality as a three-tier application when a two-tier application would have been equally technically appropriate.

Two-Tier Design

We commence our reexamination of application design architectures by examining the twotier architecture, which is a simple C# application.

■Note The simplest application design is the one-tier application (e.g., many Windows and Console applications)—that design has not been illustrated in this chapter. Its distinguishing characteristic is that all functionality resides in one layer or tier.

What

A two-tier design is an application architecture that compacts all of the functionality or application logic into a single tier that resides on one server, while data resides on a second tier (e.g., a database server). The two-tier design is suitable for Web and Windows applications.

Where

Where there is a requirement for an application that features low overhead and high performance, then the two-tier application is a common solution. It may, however, present integration inefficiencies, scalability issues, and maintenance overhead.

Why

The two-tier design can be built rapidly, offers high performance, and may be a cost-effective solution.

How

All of the functionality is encapsulated in one layer, which resides on one server (see Figure 6-3), and the data on a second server. Commonly, websites or Windows applications have used this design to rapidly develop functionality and to minimize performance overhead. However, the tight coupling between the UI, business, and data classes, which is implicit in the design, may be problematic if there is a change to data schema, for example. In this case, a solution may be to use an Adapter design pattern (refer to Chapter 11) as a short-term solution.

								C H A P T E R 6 ■ D E S I G N S T R U C T U R E	133

Figure 6-3. Two-tier design structure

The Standard: Two-Tier Design

The standard acknowledges the use of a two-tier design where there is a need for rapid development and high performance. It does caution, however, that over the medium to long term the design may encounter integration inefficiencies, and scalability, coupling, and maintenance issues.

Three-Tier Design

The three-tier design is generally considered to be the most popular design architecture in use today.

What

A three-tier design is an application architecture that separates functionality into two tiers (UI and business) that reside on separate servers, while access to data is via a third server. The three-tier design is suitable for Web and Windows applications.

Where

Where there is a requirement for an application that features high performance with a medium-to-long life expectancy, then the three-tier application is a popular solution. It supports integration efficiencies, scalability, and stability, and carries a relatively low maintenance overhead, while mildly reducing coupling concerns.

Why

The three-tier design is an alternative to a two-tier or five-tier design: it has a good mix of the advantages of the twoand five-tier architectures, but with relatively inferior de-coupling design features compared with a five-tier solution. While in theory, the user interface may be swapped between presentation types (Web or Windows), in practice, however, that is easier said than done. Commonly, problems arise because the user interface is coupled to the busi-

er.

134 C H A P T E R 6 ■ D E S I G N S T R U C T U R E

How

The functionality is divided over three layers (see Figure 6-4) with each layer residing on a separate server. Each layer is readily accessible, extensible, and maintainable.

Figure 6-4. Three-tier design structure

The Standard: Three-Tier Design

The standard acknowledges the use of a three-tier design where there is a requirement for an application that features high performance with a medium-to-long life expectancy. It cautions, however, that the business and data classes may be tightly coupled implementations to the user interface and datastore, which may cause future concern.

Five-Tier Design

The five-tier design is the elegant solution that overcomes the disadvantages of the three-tier model.

What

A five-tier design is an application architecture that separates functionality over four tiers that reside on two servers: a presentation tier resides on one server, while the UI, business, and data classes reside on a second server, and the fifth tier—the data source—is accessed via a third server. The cost of extra layers may be offset by the gain from encapsulating the UI, business, and data classes on the one server (which compares with the two-tier design and contrasts with the three-tier design). The five-tier design is suitable for Web and Windows applications.

C H A P T E R 6 ■ D E S I G N S T R U C T U R E

135

Where

Where there is a requirement for an application that features high performance with a long life expectancy, then the five-tier application is a solution. It supports integration efficiencies, scalability, stability, and loose coupling, and carries a relatively low maintenance overhead.

Why

The five-tier design has all of the advantages of the three-tier design, but with a solution to the problem of coupling the business and data classes to the implementation of the user interface and data source. These benefits are supported by the merging of the logic functionality on to one server. However, developing a five-tier application may be more expensive than a threetier application.

How

The functionality is divided over five layers (see Figure 6-5) with a presentation layer on its own server and the UI, business, and data classes residing on the same server, a feature that not only assists in decoupling, but also aids performance, as most of the grunt work is done on the same server. The data source is accessible via a third server. With this design, the functionality classes are decoupled from the presentation and data source. The UI classes are able to cater to the special needs of Web or Windows representation, and the data classes shelter the business functionality from changes to the underlying data source.