Application Architecture for .NET

1. Application Architecture for .NET: Designing Applications and Services
2. Smart Client Definition
3. Enterprise Library for .NET Framework 2.0 – December 2005
4. Composite User Interface (UI) Application Block

Application Architecture for .NET:
Designing Applications and Services
http://msdn.microsoft.com/practices/compca.../apparchch1.asp


The following diagram shows these two layers in the architecture of a .NET-based distributed application.


Figure 1.1: Component layers found in distributed applications and services built with .NET

Services and Service Integration

Components and Tiers in Applications and Services



Figure 1.2. A service-based solution

Figure 1.3 shows a simplified view of one application and its layers.


Figure 1.3. Components separated into layers according to their roles

A Sample Scenario

The proposed solution for this scenario is a component-based design that consists of a number of components, as shown in Figure 1.4.

Figure 1.4. The retail application as a set of components and related services



Figure 2.1. Component types in the retail sample scenario

The component types identified in the sample scenario design are: Component Types

Designing the Components of an Application or Service
http://msdn.microsoft.com/practices/compca.../apparchch2.asp



General Design Recommendations for Applications and Services


Designing Presentation Layers
http://msdn.microsoft.com/practices/compca...rchch2_section3

Figure 2.2 shows the component types in the presentation layer.


Figure 2.2. Presentation layer

Designing User Interface Components
Figure 2.3 shows the design of a user interface.


Figure 2.3. User interface design

Designing User Process Components
Figure 2.4 shows how the user interface and user process can be abstracted from one another.


Figure 2.4. User interfaces and user process components

User Process Component Interface
The interface of your user process components can expose the following kinds of functionality, as shown in Figure 2.5.


Figure 2.5. User process component design


Designing Business Layers
http://msdn.microsoft.com/practices/compca...rchch2_section4

Figure 2.6 shows the business layers of an application.


Figure 2.6. Business component layers

Business Components and Workflows

Business components are called by the following consumers:

• Service interfaces
• User process components
• Business workflows
• Other business components

Figure 2.7 shows a typical business component interacting with data access logic components, service interfaces, service agents, and other business components.


Figure 2.7. Business components

Figure 2.8 shows how an orchestrated business process interacts with service interfaces, service agents, and business components.


Figure 2.8. An orchestrated business process

Figure 2.10 shows a business facade used in this manner.


Figure 2.10. Using a business facade with service interfaces


Designing Data Layers
http://msdn.microsoft.com/practices/compca...rchch2_section5

Almost all applications and services need to store and access some kind of data. For example, the retail application discussed in this guide needs to store product, customer, and order data.
When working with data, you need to determine:

• The data store you are using.
• The design of the components used to access the data store.
• The format of the data passed between components, and the programming model it requires.

Figure 2.11 shows how the logical data layer of an application consists of one or more data stores, and depicts a layer of data access logic components that are used to retrieve and manipulate the data in those data stores.


Figure 2.11. Data components

Data Stores
Common types of stores include:

• Relational databases
• Messaging databases
• File system

Data Access Logic Components
Figure 2.12 shows the use of data access logic components to access data.


Figure 2.12. Data access logic components

Security, Operational Management, and Communications Policies
http://msdn.microsoft.com/practices/compca.../apparchch3.asp

Organizational policies define the rules that govern how an application is secured, how it is managed, and how the different components of the application communicate with one another and with external services. The policies affect the design of each layer of the application or service, as shown in Figure 3.1.


Figure 3.1. The effect of organizational policies on the application design


Designing the Security Policy
http://msdn.microsoft.com/practices/compca...rchch3_section1

The security policy is concerned with authentication, authorization, secure communication, auditing, and profile management, as shown in Figure 3.2.


Figure 3.2. Aspects of the security policy

Security:

Authentication

• Authentication in the Presentation Layer
• Authentication in Business Components
• Authentication in Data Access Components
• Authentication in Business Entity Components

Authorization

• User permissions and rights
• Code access security

You need to incorporate the results in the following matrix into your access control design:

• Authorization in User Interface Components
• Authorization in User Process Components
• Authorization in Business Components
• Authorization in Service Agents and Service Interfaces
• Authorization in Data Access Components
• Authorization in Business Entity Components

Secure Communication

• Secure Communication in User Interface Components
• Secure Communication in Service Agents and Service Interfaces
• Secure Communication in Data Access Components

Profile Management

Auditing

• Auditing in User Interface and User Process Components
• Auditing in Business Process Components
• Auditing in Data Access Components

Designing the Operational Management Policy
http://msdn.microsoft.com/practices/compca...rchch3_section2

The operational management policy is concerned with the ongoing, day-to-day running of the application, and covers issues such as exception management, monitoring, business monitoring, metadata, configuration, and service location, as shown in Figure 3.3.

Figure 3.3. Aspects of the operational management policy

Operational Management:

• Exception Management
• Monitoring
• Configuration
• Metadata
• Service Location

Designing the Communications Policy
http://msdn.microsoft.com/practices/compca...rchch3_section3

The communications policy defines how the components in your application will communicate with each other. The communications policy covers such issues such communication synchronicity, format, and protocol, as shown in Figure 3.4.


Figure 3.4. Aspects of the communications policy

Communication:

• Synchronicity
• Format, Schema
• Protocol

Separating Inter- and Intra-Application Communication



Figure 3.5. Implementing communication between the presentation and business tiers using the message bus



Figure 3.6. Using the message bus for integration purposes only

Physical Deployment and Operational Requirements
http://msdn.microsoft.com/practices/compca.../apparchch4.asp


Deploying Application Components
http://msdn.microsoft.com/practices/compca...rchch4_section1

Physical Deployment Environments:

• Web Farms. A Web farm is a load-balanced array of Web servers.
• Application Farms. Applications farms are conceptually similar to Web farms, but they are used to load balance requests for business components across multiple application servers.
• Database Clusters. Database clusters are used to provide high availability of a database server.
• EAI Clusters. Microsoft BizTalk® Server relies on four SQL Server databases to store its messaging and orchestration data. These databases can benefit from Windows Clustering for high availability.
• Rich Clients. In most enterprises, using rich clients implies:
  • The ability to authenticate users through Microsoft Active Directory® directory service (thus having access to a Windows Identity and Principal).
  • Access to richer state management options, including maintaining session-related state in memory. (In high scalability and availability scenarios, it is not a good idea to keep in-memory state on the server.)
  • The ability to work offline.
  • Rich clients are also better targets for the user interface of complex operations.
• Thin Clients. Thin clients usually manage HTML or even simpler UI models, so they are not typically considered a deployment target for your components. You can include .NET controls in HTML pages, but in that case you are simply using the browser as a deployment vehicle, and should consider your user interface to be rich.

Common Deployment Patterns
http://msdn.microsoft.com/practices/compca...loymentpatterns

Web-Based User Interface Scenarios
The two deployment scenarios outlined in the following discussion are common variations found when working with Web-based user interfaces.

Web Farm with Local Business Logic


Figure 4.2. Web farm with local business logic

Web Farm with Remote Business Logic
Figure 4.3 illustrates this deployment pattern.


Figure 4.3. Web farm with remote business logic


Rich Client User Interface Scenarios
The following two scenarios assume a rich client.

Rich Client with Remote Components


Figure 4.4. Rich client with remote components

Rich Client with Web Service Access
Figure 4.5 illustrates the rich client with Web access pattern.


Figure 4.5. Rich client with Web service access


Service Integration Scenarios

Service Agents and Interfaces Deployed with Business Components


Figure 4.6. A service with local business logic

Business Components Separated from Service Agents and Interfaces


Figure 4.7. Isolating service agents in a separate farm

EAI Clusters and Application Components


Figure 4.8. Separating EAI components from business components

Figure 4.8 shows user interface components on a Web farm (1) calling business components on an application farm (2), which in turn work with the application data source (3). The EAI cluster (4) has its own business components needed to perform the steps in its business workflows, and accesses other services (in this example, only internal services) through a firewall (5).


Operational Requirements

Appendices

Smart Client Definition
http://msdn.microsoft.com/smartclient/unde...on/default.aspx

Smart client (n) Definition: Smart clients are easily deployed and managed client applications that provide an adaptive, responsive and rich interactive experience by leveraging local resources and intelligently connecting to distributed data sources.



A smart client application combines the following ingredients to provide a responsive, rich, and compelling experience to its end users.


Что такое Smart Client и почему будущее за ним?

Enterprise Library for .NET Framework 2.0 – December 2005
http://msdn.microsoft.com/library/?url=/li...tml/EntLib2.asp
http://forum.vingrad.ru/index.php?showtopic=76374

The application blocks that comprise the Enterprise Library are the following:

• Caching Application Block. This application block allows developers to incorporate a local cache in their applications.
• Data Access Application Block. This application block allows developers to incorporate standard database functionality in their applications.
• Exception Handling Application Block. This application block allows developers and policy makers to create a consistent strategy for processing exceptions that occur throughout the architectural layers of enterprise applications.
• Logging Application Block. This application block allows developers to incorporate standard logging functionality in their applications.
• Security Application Block. This application block allows developers to incorporate authorization and security caching functionality in their applications.

The Enterprise Library Core

Figure 1 illustrates the interdependencies of the application blocks that make up the Enterprise Library.


Figure 1: Interdependence of application blocks

Object Builder
The ObjectBuilder is a new subsystem that is shared between Enterprise Library and the Composite User Interface (UI) Application Block. Enterprise Library uses the ObjectBuilder subsystem for tasks such as injecting configuration into block classes and connecting instrumentation classes to application blocks.

Caching Application Block

• Selecting and configuring a cache store
• Adding an item to the cache and setting its expiration date
• Removing an item from the cache
• Retrieving an item from the cache
• Flushing the cache

The following illustration shows the interrelationships between the key classes in the Caching Application Block.


Figure 2: Design of the Caching Application Block

QuickStarts

Walkthrough: Adding Items to the Cache





Walkthrough: Removing Items From the Cache


Walkthrough: Retrieving Items From the Cache


Walkthrough: Flushing the Cache


Walkthrough: Loading the Cache

The following diagram illustrates how the QuickStart retrieves data from the cache.


Figure 3: Solution elements for loading the cache



Loading the Cache Proactively

Loading the Cache Reactively

Data Access Application Block

• Using a DataReader to retrieve multiple rows of data
• Using a DataSet to retrieve multiple rows of data
• Executing a command and retrieving the output parameters
• Executing a command and retrieving a single-value item
• Performing multiple operations within a transaction
• Retrieving XML data from a SQL Server
• Updating a database with data contained in a DataSet object

The following illustration shows the interrelationship between the key classes in the Data Access Application Block.


Figure 4: Design of the Data Access Application Block

Example


QuickStarts

Walkthrough: Using a DataSet to Retrieve Multiple Rows




Walkthrough: Using a DataReader to Retrieve Multiple Rows





Walkthrough: Retrieving Multiple Rows as XML


Walkthrough: Executing a Command and Accessing Output Parameters



Walkthrough: Executing a Command and Accessing a Single-Item Result




Walkthrough: Executing a Command and Accessing a Single-Item Result




Walkthrough: Using a DataSet to Update a Database

Exception Handling Application Block

• Logging an Exception
• Wrapping an Exception
• Replacing an Exception
• Propagating an Exception
• Displaying User-Friendly Messages
• Notifying the User
• Aiding Support Staff

Figure 8 shows the interrelationships between the key classes in the Exception Handling Application Block.


Figure 8: Design of the Exception Handling Application Block

When to Use the Exception Handling Application Block
Figure 5 illustrates examples of cross-layer and single-application component exception handling.


Figure 5: Examples of exception handling policies

Without the Exception Handling Application Block, typical exception handling code for a data access component might look like the following example.

Code similar to this would be repeated in all the routines that perform different data access queries. To change the behavior of the exception handling code, you must update each routine that contained this code.
On the other hand, with the Exception Handling Application Block, the same application would have the following code.


Exception Handling Process and the Exception Handling Application Block
Figure 6 illustrates the basic steps that your application should perform to handle an exception.


Figure 6: Exception handling process

Exception Propagation
There are three main ways to propagate exceptions:
Let the exception propagate automatically. With this approach, you do nothing and deliberately ignore the exception. This causes the control to move immediately from the current code block up the call stack until a catch block with a filter that matches the exception type is found.
Catch and rethrow the exception. With this approach, you catch and react to the exception, and clean up or perform any other required processing within the scope of the current method. If you cannot recover from the exception, you rethrow the same exception to your caller.
Catch, wrap, and throw the wrapped exception. As an exception propagates up the call stack, the exception type becomes less relevant. When an exception is wrapped, a more relevant exception can be returned to the caller. This is illustrated in Figure 7.


Figure 7: Propagating exceptions

QuickStarts

Exception Handling Basic QuickStart

Walkthrough: Propagating the Original Exception
This walkthrough demonstrates the steps to enable the original exception to propagate. The process is shown in Figure 9.


Figure 9: Propagating the original exception

Walkthrough: Wrapping One Exception in Another


Figure 17: Wrapping one exception in another

Walkthrough: Replacing One Exception with Another
This walkthrough demonstrates the steps to replace one exception with another before propagating the exception. The process is shown in Figure 10.


Figure 10: Replacing one exception with another

Walkthrough: Processing and Resuming Execution
This walkthrough demonstrates the steps to run a series of exception handlers before resuming execution in the application. This process is shown in the Figure 11.


Figure 11: Processing and resuming execution

Exception Handling with Logging QuickStart

Walkthrough: Logging an Exception
This walkthrough demonstrates the steps to log exception information. This process is shown in Figure 12.


Figure 12: Logging an exception

Walkthrough: Notifying the User
This walkthrough demonstrates the steps to send a friendly exception message to the user and still allow support staff to access information regarding the originating exception. This process is shown in Figure 13.


Figure 13: Notifying the user

Logging Application Block

• Populating and raising events from code
• Populating a log message with additional context information
• Tracing activities and propagating context information
• Checking filter status before constructing log messages.
• Configuring options for trace listeners
• Directing different event types to different trace listeners
• Configuring log filters
• Configure logging to be performed from a central location
• Creating a custom trace listener

Figure 14 illustrates the design of the Logging Application Block.


Figure 14: Design of the Logging Application Block

QuickStarts

Walkthrough: Populating and Raising an Event from Code



Walkthrough: Populating a Log Message with Additional Context Information


Walkthrough: Tracing Activities and Propagating Context Information
This walkthrough demonstrates the steps to trace activities and propagate context information from code. The sequence of method calls with tracing information is shown in Figure 15.






Walkthrough: Creating a Custom Trace Listener

Security Application Block

• Obtaining a temporary token for an authenticated user
• Authenticating a user using a token
• Ending a user session (expire a token)
• Determining if a user is authorized to perform a task

The Security Application Block is designed to externalize the implementation of the authorization and caching provider from a running application. This design lets you change implementations without changing the code of the application. The following illustration shows the interrelationship between the key classes in the Security Application Block.


Figure 16: Design of the Security Application Block

QuickStarts

Walkthrough: Obtain a Temporary Token for an Authenticated User




Walkthrough: Authenticate a User Using a Token


Walkthrough: Terminate a User Session





Walkthrough: Determine Whether a User is Authorized to Perform a Task

Pegas
Слабо перевести и в ФАК положить? Цены б тебе не было

Занятная штука...
-------------

2arilou
Чё там переводить-то? Словарик в руки - и сам себе переводчик