提升.NET平台应用架构设计：2.0指南

下载需积分: 10 | PDF格式 | 3.09MB | 更新于2025-01-08 | 175 浏览量 | 举报

《应用架构指南2.0》是一份旨在提升开发者在微软平台上构建应用程序效率的专业指南。该文档主要面向解决方案架构师和开发负责人，提供了针对Microsoft .NET平台应用设计层面的深入指导。它关注的是最常见的应用程序类型，并强调了将应用程序功能划分为层、组件和服务的重要性，同时揭示了这些设计特性的关键要素。该指南的核心内容涵盖了如何在.NET平台上进行应用设计，包括但不限于模块化结构、服务导向架构（SOA）原则、以及企业级应用程序的设计模式，如三层架构（Presentation, Business Logic, Data Access Layers）。它倡导将业务逻辑与数据访问解耦，以便于维护、测试和扩展。此外，它还强调了微服务架构的应用，通过将大型应用分解为小型、独立的服务单元，来提高系统的可扩展性和可靠性。设计方面，该指南可能会涉及架构模式如Model-View-Controller（MVC）、Repository pattern和Enterprise Application Block (EAB)等，这些都是.NET设计中的常见实践。指南还可能探讨如何利用.NET框架提供的特性，如.NET Core、ASP.NET、Entity Framework等，来构建高效、安全和可维护的应用程序。值得注意的是，文档中的示例、公司名、域名、电子邮件地址等均为虚构，除非特别注明，不应视为真实存在。用户需确保遵循所有适用的版权法规定，并且在复制、存储或以任何形式传播文档内容时，必须得到Microsoft Corporation的明确书面许可。同时，微软可能拥有涵盖文档主题的专利、商标、版权或其他知识产权，仅在明确授权下方可使用。《Application Architecture Guide 2.0》是一本实用的工具书，为开发人员提供了在微软平台上创建高质量、可扩展的软件应用所需的系统性指导，是每个致力于提升技术水平和团队协作效率的开发者的必备参考资料。

applications, or larger applications that contain business rules, consider using a layered

design that separates presentation, business, and data-access functionality into separate

layers. In addition, the interaction between the presentation and business layers should be

message-based, which is better suited to the stateless nature of Web application requests.

On the client, you can improve the user experience by using dynamic HTML (DHTML),

JavaScript, Asynchronous JavaScript and XML (AJAX), or a combination of all three

technologies. For example, with AJAX you can implement lazy loading and partial updates to

page content, which will improve performance and prevent the “reload flash” when a user

interacts with the page.

For more information, see Chapter 15, “Web Applications.”

• How to design a rich client application

For reusability and testability, separate the presentation logic from the UI implementation

by using a design patterns such as Model-View-Controller (MVC). Design to provide a

suitable and usable interface in terms of layout, navigation, choice of controls, and

localization. Extract business rules and other tasks not related to the UI into a separate

business layer. Use a message-based interface to communicate with services deployed on

separate physical tiers. Avoid tight coupling to objects in other layers by using common

interface definitions, abstract base classes, or message-based communication. For example,

implementing the Dependency Injection and Inversion of Control patterns can provide a

shared abstraction between layers.

For more information, see Chapter 17, “Rich Client Applications.”

• How to design a rich Internet application (RIA)

Plan to use a Web-based infrastructure, because RIA implementations require an

infrastructure similar to that of Web applications. Design your application to run in the

browser sandbox. When designing an RIA, consider using a single page that changes

dynamically as the user works with the application. Multi-page designs are more complex in

an RIA, and require additional considerations such as deep linking and UI screen navigation.

Design for usability, such as the ability to pause and navigate to the appropriate point in a

workflow without restarting the whole process. RIA implementations have a small footprint

on the client, but require a browser plug-in. Design for scenarios in which the browser plug-

in is not already installed, including non-interruptive plug-in installation and displaying

informative error messages if an installation problem should occur.

For more information, see Chapter 16, “Rich Internet Applications.”

• How to design a service

When designing a service, there are general guidelines that should be followed; for

example, design for extensibility, use coarse-grained interfaces, never assume how the

client will use the service, and decouple the interface from the implementation. The best

way to support these guidelines is to introduce a service layer in your design that sits

Application Architecture Guide 2.0a

Microsoft patterns & practices

between consumers of the service and the business layer that supports the service. Within

the service layer, you define interface contracts, classes to translate between the interface

and the business layer, and concrete classes that implement the interface. In most cases,

interaction with the business layer is accomplished by using a Façade pattern, which allows

you to combine multiple business operations into a single application-scoped service

operation.

For more information, see Chapter 18, “Services.”

• How to design a mobile application

Design specifically for the device instead of trying to reuse the architecture or UI from a

desktop application or a Web application. When choosing which device types to support,

consider screen size and format, CPU performance characteristics, memory and storage

space, development tool and environment support, as well as user requirements and

organizational constraints. Design your caching, state management, and data-access

mechanisms with intermittent network connectivity in mind.

For more information, see Chapter 19, “Mobile Applications.”

Architecture Frame

The following guidelines will help you to understand the fundamental cross-cutting factors you

must consider when designing your chosen application type. Use these guidelines as a starting

point toward understanding how to think about key functionality that cuts across layers and

tiers. For example, your exception-management strategy should be designed to be consistent

across your entire application, and not with just a single layer in mind.

• How to design your exception-management strategy

Use structured exception handling to build robust code. Use exceptions instead of error

codes where possible. Do not reveal internal system or application details, such as stack

traces, SQL statement fragments, and so on. Ensure that this type of information is not

allowed to propagate to the end user, or beyond your current trust boundary. Fail securely

in the event of an exception, and make sure that your application denies access and is not

left in an insecure state. Use finally blocks to guarantee that resources are cleaned up when

exceptions occur; for example, close your database connections in a finally block. Do not log

sensitive or private data such as passwords, which could be compromised. When the

exception contains user input in the exception message, ensure that you sanitize and

validate it; for example, if you return an HTML error message, you should encode the

output to avoid script injection.

For more information, see Chapter 3, “Architecture and Design Guidelines.”

Application Architecture Guide 2.0a

Microsoft patterns & practices

• How to instrument your application

Instrumentation is used when you have a specific problem and you need additional

information in order to solve that problem. This could be a debugging issue, a performance

issue, a security issue, a manageability issue, and so on. This is different than logging in that

logging is a general approach to pushing information into log files that might need to be

audited in the future, versus a targeted approach to get information for a specific problem.

Options for instrumentation include event tracing for Microsoft® Windows®, trace and

debug classes, custom performance counters, and Windows Management Instrumentation

(WMI). For logging, consider the Logging Application Block in the Enterprise Library.

For more information, see Chapter 3, “Architecture and Design Guidelines.”

• How to design for transactions

Use connection-based transactions when accessing a single data source. Where you cannot

use transactions, implement compensating methods to revert the data store to its previous

state. Avoid holding locks for long periods; for example, when using long-running atomic

transactions. Consider using compensating locks for long-running transactions. If the chance

of a data conflict from concurrent users is low (for example, when users are generally

adding data or editing different rows), consider using optimistic locking during data access.

If the chance of a data conflict from concurrent users is high (for example, when users are

likely to be editing the same rows), consider using pessimistic locking during data access. If

transactions take a long time to complete, consider using asynchronous transactions that

call back to the client when complete. You can perform transactions using T-SQL

commands, ADO.NET, or System.Transaction. T-SQL transactions are most efficient for

server-controlled transactions on a single data store. Keep transactions as short as possible,

consider your isolation level, and keep read operations to a minimum inside a transaction.

For more information, see Chapter 3, “Architecture and Design Guidelines.”

Presentation Layer

The following guidelines will help you to understand the fundamental factors you must consider

when designing the presentation layer for your application. Use these guidelines as a starting

point toward understanding key concerns, such as how to validate input on the client and on

the server, and how to choose between the Model-View-Controller (MVC) and Model-View-

Presenter (MVP) patterns.

• How to validate input

Assume that all input data is malicious. Constrain, reject, and sanitize your input because it

is easier to validate data for known valid types, patterns, and ranges than it is to validate

data by looking for known bad characters. Validate data for type, length, format, and range.

Consider using regular expressions for validating the inputs. For an improved user

experience, consider using client-side validation, but always perform validation at the server

as well. Encode your output.

Application Architecture Guide 2.0a

Microsoft patterns & practices

For more information, see Chapter 3, “Architecture and Design Guidelines.”

• How to use the MVC pattern

To use the Model-View-Controller (MVC) pattern effectively, you must understand the

division of labor within the MVC triad (the Model, the View, and the Controller). You must

also understand how the three parts of the triad communicate with each other to process

requests from user input. The Model represents data, and the View is the UI, which displays

the data to the user and contains controls for the user to interact with the data and the

application. The Controller is responsible for handling requests, initializing the Model and

choosing the appropriate View. Common Web implementations use HTTP handlers or

Internet Server API (ISAPI) filters to intercept requests and send them directly to a

controller. There are two main variations of the MVC pattern: the Passive Model and the

Active Model. In the Passive Model pattern, changes to the Model are only captured when

the Controller processes a request. However, in the Active Model pattern, an Observer

pattern implementation can be used to notify the View and/or the Controller when changes

occur in the Model. One of the limitations with this pattern is that, because the controller is

responsible for intercepting and handling requests, you lose capabilities associated with the

View such as the ability to handle control events and the use of viewstate in ASP.NET.

For more information, see Chapter 10, “Presentation Layer Guidelines.”

• How to use the MVP pattern

The Model-View-Presenter (MVP) pattern is very similar to the MVC pattern, with the main

difference being that Views handle requests and pass them to a presenter, which provides

controller logic. Similar to the controller in MVC, the Presenter is responsible for processing

requests and initializing the model. The main advantage of using this pattern over MVC is

that, because the view handles requests, you also have support for control events and the

ability to maintain the state of controls in the view. There are two main variations on this

pattern, Passive View and Supervising Controller. With Passive View, requests are

intercepted by the View and passed to the Presenter, and then the Presenter initializes

fields in the View through an interface. This variation completely decouples the view from

the Model and provides the highest level of testability. With Supervising Controller, the

View passes requests to the Presenter, the Presenter notifies the View when the Model is

initialized, and the View accesses the Model directly. This variation is useful when you have

a lot of data that needs to be presented in the View, which makes Passive View impractical.

For more information, see Chapter 10, “Presentation Layer Guidelines.”

Business Layer

The following guidelines will help you to understand fundamental factors you must consider

when designing the business layer for your application. Use these guidelines as a starting point

Application Architecture Guide 2.0a

Microsoft patterns & practices

toward understanding key concerns, such as when to use business entities, how to implement

business components, and how to expose your business layer as a service.

• How to implement business entities

If you are designing a small Web application or a service, and you want to take advantage of

the disconnected behavior they provide, consider using DataSets. If you are working with

content-based applications that have few or no business rules, consider using XML. If you

have complex business rules related to the business domain, or if you are designing a rich

client where the domain model can be initialized and held in memory, consider using

custom Domain Model objects. If your tables or views in the database represent the

business entities used by your application, consider using custom objects. If the data you

are consuming is already in XML format, or if you are working with read-only document-

based data, consider using custom XML objects.

For more information, see Chapter 11, “Business Layer Guidelines.”

• How to implement business components

The type of business component you implement depends on your business rules. If you

have volatile business rules, consider storing them in a separate rules engine. If you want

your business rules to be separate from the business data, consider using business process

components. If your business processes involve multiple steps with long-running

transactions, consider using business workflow components. A well-designed business

component exposes data and functionality based on how the data is used, and abstracts the

underlying data store and service. Do not mix unrelated functionality within a business

component; for example, do not mix data access logic and business logic within the same

component. Consider designing consistent input and output data formats for business

components.

For more information, see Chapter 11, “Business Layer Guidelines.”

• How to design application service façades

A well-designed application service façade exposes a simple interface by encapsulating

cohesive behavior that is specific to a set of related business operations. Avoid including

business logic in a service interface in order to improve reusability and maintainability and

reduce duplication of code. Consider using standard protocols such as the SOAP as the

communication medium to ensure maximum compatibility with a range of clients.

For more information, see Chapter 11, “Business Layer Guidelines.”

Data Access Layer

The following guidelines will help you to understand the fundamental factors you need to

consider when designing the data layer for your application. Use these guidelines as a starting

point toward understanding the key concerns, such as how to design your data access layer,

Application Architecture Guide 2.0a

Microsoft patterns & practices

剩余386页未读，继续阅读

KelvinYuan

粉丝: 0
资源: 4

提升.NET平台应用架构设计：2.0指南

微软App Arch Guide 2.0：平台架构指南

.NET平台上的应用架构指南2.0

.NET平台应用架构指南2.0

\应用程序架构指南Application Architecture Guide 2.0

Application Architecture Guide v2.pdf

微软架构必读 App Arch Guide 2.0 Overview

A Practical Guide to TPM 2.0 Using the Trusted Platform Module

.A.Practical.Guide.to.TPM.2.0

Zend Framework 2 Application Development

JDBC Developers Guide Reference.rar

最新资源