微软.NET平台应用架构指南2.0

5星 · 超过95%的资源需积分: 15 117 浏览量更新于2024-08-01 收藏 3.1MB PDF 举报

“微软官方架构设计文档2.0——在.NET平台上设计应用程序指南” 这份微软官方文档，名为“Application Architecture Guide 2.0”，是专为.NET平台上的应用架构设计而编写的，它提供了丰富的信息和实用的例子，帮助开发者和架构师理解如何在.NET平台上构建高效且可扩展的应用程序。文档采用浅显易懂的英文撰写，适合不同层次的读者阅读。文档内容涵盖了多个关键主题： 1. **架构基础**：这部分可能包括了对软件架构的基本定义，以及为什么良好的架构设计对于项目的成功至关重要。它可能会讨论不同的架构模式，如分层架构、微服务架构等，并解释每种模式的优缺点。 2. **.NET平台介绍**：文档可能深入介绍了.NET Framework或.NET Core的特点和优势，包括其运行时环境、类库支持、开发工具（如Visual Studio）以及跨平台能力。 3. **设计原则**：这里可能会涵盖常见的设计原则，如单一职责原则(SRP)、开闭原则(OCP)、里氏替换原则(LSP)、接口隔离原则(ISP)和依赖倒置原则(DIP)，这些都是创建可维护和可扩展代码的基础。 4. **架构决策**：文档可能会指导读者如何进行技术选型，考虑性能、可扩展性、安全性、可维护性和成本等因素。它可能还会讨论如何权衡各种决策，以及如何记录和沟通这些决策。 5. **模块化与组件化**：文档可能会强调如何将大型应用分解为独立的模块或组件，以便于管理和升级。这可能涉及到接口设计、服务定位器模式、依赖注入等概念。 6. **数据访问策略**：对于.NET平台，文档可能涵盖了ORM（对象关系映射）工具如Entity Framework的使用，以及数据库设计和优化的考量。 7. **错误处理与日志记录**：文档可能会讨论如何有效地处理异常，确保系统的健壮性，以及如何实现合适的日志记录策略来辅助故障排查。 8. **安全性与隐私**：在讲解架构设计时，安全问题不容忽视。文档可能会涉及身份验证、授权、加密、防止SQL注入和跨站脚本攻击(XSS)等话题。 9. **性能优化**：文档可能提供了一些最佳实践，如缓存策略、并发处理、异步编程和资源管理，以提升应用性能。 10. **测试与部署**：自动化测试、持续集成/持续部署(CI/CD)流程以及云部署策略也可能是讨论的重点，以确保应用的质量和可部署性。此外，文档中可能还包含对版权和知识产权的声明，提醒用户遵守相关法律法规，未经许可不得复制或以任何形式传播文档内容。尽管文档中的例子可能是虚构的，但它们通常能够反映真实世界中的问题和解决方案，帮助读者更好地理解和应用理论知识。

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页未读，继续阅读

yanglinjingshu

粉丝: 37
资源: 15

微软.NET平台应用架构指南2.0

微软多层架构的文档与示例

微软平台下的编程架构

微软架构师培训文档.zip

深入解析OpenMES架构设计文档

AZ-304微软Azure架构设计考试指南

微软应用程序架构设计指南 第二版

WDK驱动开发微软官方帮助文档

微软云应用架构设计模式指南

AZ-301考试精华题库：250道必过微软Azure架构设计全真模拟

微软应用架构指南：设计与决策关键

最新资源

微软应用程序架构设计指南第二版