Summary from Application Architecture Guide 2.0(Designing Applications on the .NET Platform). You can get it from here.
Application Types
Your choice of application type will be related both to the technology constraints and the typeof user experience you plan to deliver. Use scenarios to help you choose an application type. For example, if you want to support rich media and graphics delivered over the Internet, a rich Internet application (RIA) is probably the best choice. However, if you want to support data entry with forms in an occasionally connected scenario, a rich client is probably the best choice.Use the table below to review and understand each application type.
Application type Description
Mobile Application
?
Can be developed as a Web application or a rich client application.
?
Can support occasionally connected scenarios.
?
Runs on devices with limited hardware resources.
Rich Client Application
?
Usually developed as a stand-alone application.
?
Can support disconnected or occasionally connected scenarios.
?
Uses the processing and storage resources of the local machine.
Rich Internet Application
?
Can support multiple platforms and browsers.
?
Can be deployed over the Internet.
?
Designed for rich media and graphical content.
?
Runs in the browser sandbox for maximum security.
?
Can use the processing and storage resources of the local machine.
Service Application
?
Designed to support loose coupling between distributed components.
?
Service operations are called using XML-based messages.
?
Can be accessed from the local machine or remotely, depending on the transport protocol.
Web Application
?
Can support multiple platforms and browsers.
?
Supports only connected scenarios.
?
Uses the processing and storage resources of the server.
Architectural Styles
Your choice of architectural styles will depend upon your application type, the requirements and constraints of your application, the scenarios you want to support, and—to some extent—the styles with which you are most familiar and comfortable. Your choice of architectural styles represents a set of principles that your design will follow—an organizing set of ideas that you can use to keep your design cohesive and focused on your key objectives and scenarios. Use the table below to review and understand the key set of architectural styles.
Architecture style Description
Client-Server
Segregates the system into two computer programs where one program, the client, makes a service request to another program, the server.
Component-Based Architecture
Decomposes application design into reusable functional or logical components that are location-transparent and expose well-defined communication interfaces.
Layered Architecture
Partitions the concerns of the application into stacked groups (layers).
Message-Bus
A software system that can receive and send messages that are based on a set of known formats, so that systems can communicate with each other without needing to know the actual recipient.
N-tier / 3-tier
Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.
Object-Oriented
An architectural style based on division of tasks for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object.
Separated Presentation
Separates the logic for managing user interaction from the UI view and from the data with which the user works.
Service-Oriented Architecture (SOA)
Refers to applications that expose and consume functionality as a service using contracts and messages.
Quality Attributes
Use the quality attributes to focus your thinking around critical problems that your design should solve. Addressing quality attributes in your design rather than during development will improve the likelihood that your application will be successful in the long term. Use the table below to review and understand each quality attribute.
Category Description
Availability
Availability defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period. Availability will be affected by system errors, infrastructure problems, malicious attacks, and system load.
Conceptual Integrity
Conceptual integrity defines the consistency and coherence of the overall design. This includes the way that components or modules are designed, as well as factors such as coding style and variable
naming.
Flexibility
Flexibility is the ability of a system to adapt to varying environments and situations, and to cope with changes to business policies and rules. A flexible system is one that is easy to reconfigure or adapt in response to different user and system requirements.
Interoperability
Interoperability is the ability of diverse components of a system or different systems to operate successfully by exchanging information, often by using services. An interoperable system makes it easier to exchange and reuse information internally as well as externally.
Maintainability
Maintainability is the ability of a system to undergo changes to its components, services, features, and interfaces as may be required when adding or changing the functionality, fixing errors, and meeting new business requirements.
Manageability
Manageability defines how easy it is to manage the application, usually through sufficient and useful instrumentation exposed for use in monitoring systems and for debugging and performance tuning.
Performance
Performance is an indication of the responsiveness of a system to execute any action within a given interval of time. It can be measured in terms of latency or throughput. Latency is the time taken to respond to any event. Throughput is the number of events that take place within given amount of time.
Reliability
Reliability is the ability of a system to remain operational over time. Reliability is measured as the probability that a system will not fail to perform its intended functions over a specified interval of time.
Reusability
Reusability defines the capability for components and subsystems to be suitable for use in other applications and in other scenarios. Reusability minimizes the duplication of components and also the implementation time.
Scalability
Scalability is the ability of a system to function well when there are changes to the load or demand. Typically, the system will be able to be extended by scaling up the performance of the server, or by scaling out to multiple servers as demand and load increase.
Security
Security defines the ways that a system is protected from disclosure or loss of information, and the possibility of a successful malicious attack. A secure system aims to protect assets and revent unauthorized modification of information.
Supportability
Supportability defines how easy it is for operators, developers, and users to understand and use the application, and how easy it is to resolve errors when the system fails to work correctly.
Testability
Testability is a measure of how easy it is to create test criteria for the system and its components, and to execute these tests in order to determine if the criteria are met. Good testability makes it more likely that faults in a system can be isolated in a timely and effective
manner.
Usability
Usability defines how well the application meets the requirements of the user and consumer by being intuitive, easy to localize and globalize, able to provide good access for disabled users, and able to provide a good overall user experience.
Architecture Frame
The architecture frame is a collection of hotspots that represent key engineering decisions. Each represents an opportunity to improve your design and build a technically more effective architecture. This architecture frame is part of the larger architecture meta-frame, and is used throughout the guide to organize key patterns, principles and practices. These categories help you to focus on the most important areas, and obtain the most meaningful and actionable guidance.
Category Description
Authentication and Authorization
Authentication and authorization allow you to identify the users of your application with confidence, and to determine the resources and operations to which they should have
access.
Caching and State
Caching improves performance, reduces server round trips, and can be used to maintain the state of your application.
Communication
Communication strategies determine how you will communicate between layers and tiers, including protocol, security, and communication-style decisions.
Composition
Composition strategies determine how you manage component dependencies and the interactions between components.
Concurrency and Transactions
Concurrency is concerned with the way that your application handles conflicts caused by multiple users creating, reading, updating, and deleting data at the same time. Transactions are used for important multi-step operations in order to treat them as though they were atomic, and to recover in the case of a failure or error.
Configuration Management
Configuration management defines how you configure your application after deployment, where you store configuration data, and how you protect the configuration data.
Coupling and Cohesion
Coupling and cohesion are strategies concerned with layering, separating application components and layers, and organizing your application trust and functionality boundaries.
Data Access
Data access strategies describe techniques for abstracting and accessing data in your data store. This includes data entity design, error management, and managing database connections.
Exception Management
Exception-management strategies describe techniques for handling errors, logging errors for auditing purposes, and notifying users of error conditions.
Logging and Instrumentation
Logging and instrumentation represents the strategies for logging key business events, security actions, and provision of an audit trail in the case of an attack or failure.
User Experience
User experience is the interaction between your users and your application. A good user experience can improve the efficiency and effectiveness of the application, while a poor user experience may deter users from using an otherwise welldesigned application.
Validation
Validation is the means by which your application checks and verifies input from all sources before trusting and processing it. A good input and data-validation strategy takes into account
not only the source of the data, but also how the data will be used, when determining how to validate it.
Workflow
Workflow is a system-assisted process that is divided into a series of execution steps, events, and conditions. The workflow may be an orchestration between a set of components and systems, or it may include human collaboration.
Designing Your Architecture
Step 1: Identify Architecture Objectives.
Consider the following key points as you identify your architecture objectives:
? Understand your architecture goals at the start.
? Understand who will consume your architecture.
? Understand your constraints.
Step 2: Key Scenarios.
These use cases are especially important in shaping the success of your application:
? Business-Critical
? High Impact
Consider the following when planning your stories (User Stories, System Stories, and Business Stories):
?
Early in the project, reduce risk by creating a candidate architecture that supports architecturally significant end-to-end scenarios that exercise all layers of the architecture.
?
Using your architecture model as a guide, make changes to your architecture, design, and code to meet your scenarios, functional requirements, technological requirements, quality attributes, and constraints.
?
Create an architecture model based on what you know at the time, and define a list of questions that must be addressed in subsequent stories and iterations.
?
After you make sufficient significant changes to the architecture and design, consider creating a story that reflects these changes. Batch together the small changes in the architecture and design and address them together.
Step 3: Application Overview.
An application overview consists of the following steps:
? Determine your application type.
? Understand your deployment constraints.
? Identify important architecture styles.
?
Determine relevant technologies.
Choosing Application Types
Mobile Applications
Benefits
?
Can support handheld devices.
?
Provide availability and ease of use for out-of-office users
?
Can support offline and occasionally-connected scenarios.
Considerations
?
Input and navigation limitations
?
Limited screen display area
Rich Client Applications
Benefits
?
Can leverage client resources.
?
Provide better responsiveness, rich UI functionality, and improved user experience.
?
Provide highly dynamic and responsive interaction.
?
Can support offline and occasionally connected applications.
Considerations
?
Deployment complexity; However, a range of installation options are available, such as ClickOnce, Windows Installer and XCOPY
?
Can be challenging to version over time
?
Platform-specific
Rich Internet Applications (RIA)
Benefits
?
Provide the same rich UI capability as rich clients.
?
Provide support for rich media and graphics display.
?
Simple deployment and the distribution capabilities (reach) of Web clients.
Considerations
?
Larger application footprint on the client machine compared to a Web application
?
Restrictions on leveraging client resources compared to a rich client application
?
Requires deployment of the .NET or Microsoft Silverlight® run time on the client
Services Applications
Benefits
?
Provide loosely coupled interactions between client and server.
?
Can be consumed by different and unrelated applications.
?
Supports interoperability.
Considerations
?
No UI support
?
Client is dependent on network connectivity
Web Applications
Benefits
?
Has broad reach, and a standardsbased UI across multiple platforms.
?
Offers ease of deployment and change management.
Considerations
?
Dependency on network connectivity (must be connected all of the time)
?
Difficulty in providing a rich UI
Choosing Deployment Scenario
Non-distributed Deployment
Advantages
? Non-distributed architecture is less complex than distributed architecture.
? Non-distributed architecture has performance advantages gained through local calls.
Disadvantages
? With non-distributed architecture, it is difficult to share business logic with other applications.
? With non-distributed architecture, server resources are shared across layers. This can be good or bad. Layers may work well together and result in optimized usage because one of them is always busy. However, if one layer requires disproportionately more resources, another layer may be starved of resources.
Distributed Deployment
Advantages
?
Distributed architecture has the ability to scale out and load-balance business logic independently.
?
Distributed architecture has separate server resources that are available for separate layers.
?
Distributed architecture is flexible.
Disadvantages
?
Distributed architecture has additional serialization and network latency overheads due to remote calls.
?
Distributed architecture is potentially more complex and more expensive in terms of total cost of ownership (TCO).
Choosing Architecture Styles
Architecture styles can be organized by their key focus area.
Category
|
Architecture styles
|
Communication
|
Service-Oriented Architecture (SOA), Message Bus, Pipes and Filters
|
Deployment
|
Client/server, 3-Tier, N-Tier
|
Domain
|
Domain Model, Gateway
|
Interaction
|
Separated Presentation
|
Structure
|
Component-Based, Object-Oriented, Layered Architecture
|
Consider the following points when choosing architecture styles.
Client/Server
Segregates the system into two computer programs where one program, the client, makes a service request to another program, the server.
Consider the client/server architecture style if:
?
Your application is server-based and will support many clients.
?
You are creating Web-based applications exposed through a Web browser.
?
You are implementing business processes that will be used by people throughout the organization.
?
You want to centralize data storage, backup, and management functions.
?
Your application must support different client types and different devices.
Component-based
Decomposes application design into reusable functional or logical components that are location-transparent and expose well-defined communication interfaces.
Consider the component-based architecture style if:
?
You already have suitable components, or can obtain suitable components from third-party suppliers.
?
Your application will predominantly execute procedural style functions, perhaps with little or no data input.
?
Your application is relatively simple, and does not warrant a full layered architecture.
?
Your application has specific requirements that do not include a UI or business processes.
?
You want to be able to combine components written in different code languages.
?
You want to create a pluggable architecture that allows you to easily replace and update individual components.
Layered
Partitions the concerns of the application into stacked groups (layers).
Consider the layered architecture style if:
?
Your application is complex, and you want to mitigate that complexity by grouping functionality into different areas of concern.
?
You want to improve the maintainability and extensibility of the application, by minimizing dependencies.
?
You already have applications that expose suitable business processes through service interfaces.
?
Your application must support different client types and different devices.
?
You want to implement complex and/or configurable business rules and processes.
Message-bus
Is a software system that can receive and send messages that are based on a set of known formats, so that systems can communicate with each other without needing to know the actual recipient.
Consider the message-bus architecture style if:
?
You have existing applications that interoperate with each other to perform tasks.
?
You are implementing a task that requires interaction with external applications.
?
You are implementing a task that requires interaction with applications hosted in a different environment.
?
You have existing applications that perform specific tasks, and you want to combine those tasks into a single operation.
?
You want to perform operations asynchronously, such as order processing or workflow.
?
You are implementing a publisher/subscriber application.
Separated Presentation Architectural Style
Consider the Separated Presentation architectural style, such as Model-View-Controller (MVC), if:
?
You want improved testability and simpler maintenance of UI functionality.
?
You want to separate the task of creating the UI from the logic code that drives it.
?
Your UI view does not contain any request-processing code.
?
Your UI processing code does not implement any business logic.
N-tier / 3-tier
Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.
Consider either the N-tier or the 3-tier architectural style if:
?
The processing requirements of the layers in the application differ. Processing in one layer could absorb sufficient resources to slow the processing in other layers.
?
The security requirements of the layers in the application may differ. For example, the presentation layer will not store sensitive data, while this may be stored in the business and data layers.
?
You want to be able to share business logic between applications.
?
You have sufficient hardware to allocate the required number of servers to each tier.
Consider the 3-tier architectural style if:
?
You are developing an intranet application where all servers are located within the private network.
?
You are developing an Internet application, and security requirements do not restrict implementing business logic within the public-facing Web or application server.
Consider using more than three tiers if:
?
Security requirements dictate that business logic cannot be deployed to the perimeter network.
?
The application makes heavy use of resources and you want to offload that functionality to another server
Object-oriented
A programming style based on division of tasks for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to that object.
Consider the object-oriented architecture style if:
? You want to model the application based on real-world objects and actions.
? You already have suitable objects and classes that match the design and operational requirements.
? You need to encapsulate logic and data together in reusable components.
Separated Presentation
Separates the logic for managing user interaction from the UI view and from the data with which the user works.
Service-Oriented Architecture (SOA)
Represents applications that expose and consume functionality as a service using contracts and messages.
Consider the service-oriented architecture style if:
?
You have access to suitable services or can purchase suitable services exposed by a hosting company.
?
You want to build applications that compose a variety of services into a single UI.
?
You are creating Software plus Service (S+S), Software as a Service (SaaS), or cloud-based applications.
?
You need to support message-based communication between segments of the application.
?
You need to expose functionality in a platform-independent way.
?
You want to take advantage of federated services, such as authentication.
?
You want to expose services that are discoverable through directories and can be used by clients that have no prior knowledge of the interfaces.
Choosing Technologies
Consider the following questions:
? Which technologies help you support your chosen architectural styles?
? Which technologies help you support your application type?
? Which technologies help you support key quality attributes for your application?
Mobile
? .NET Compact Framework.
? ASP.NET mobile controls.
? Silverlight.
Rich Client
? Windows Forms.
? Windows Forms with WPF user controls.
? WPF.
? XAML Browser Application (XBAP) using WPF.
Rich Internet Client (RIA)
? Silverlight.
? Silverlight with AJAX.
Web Applications
? ASP.NET Web Forms.
? ASP.NET Web Forms with AJAX.
? ASP.NET Web Forms with Silverlight controls.
? ASP.NET MVC.
? ASP.NET Dynamic Data.
Service Applications
? Windows Communication Foundation (WCF).
? ASP.NET Web services (ASMX).
Step 4: Key Hotspots.
Architecture Frame
You can use the following architecture frame to identify cross cutting concerns in your design.
Authentication and Authorization
|
?
How to choose an authentication strategy
?
How to choose an authorization strategy
?
How to flow identity across layers and tiers
?
How to store user identities when not using the Microsoft Active
Directory® directory service
|
Caching and State
|
?
How to choose an appropriate caching technology
?
How to determine what data to cache
?
How to determine where to cache the data
?
How to determine the expiration policy
|
Communication
|
?
How to choose appropriate protocols for communication across
layers and tiers
?
How to design loose coupling across layers
?
How to perform asynchronous communication
?
How to pass sensitive data
|
Composition
|
?
How to choose a composition pattern for the UI)
?
How to avoid dependencies between modules in the UI
?
How to handle communication between modules in the UI
|
Concurrency and
Transactions
|
?
How to handle concurrency between threads
?
How to choose between optimistic and pessimistic concurrency
?
How to handle distributed transactions
?
How to handle long-running transactions
|
Configuration
Management
|
?
How to determine what information needs to be configurable
?
How to determine where and how to store configuration
information
?
How to protect sensitive configuration information
?
How to handle configuration information in a farm/cluster
|
Coupling and Cohesion
|
?
How to choose an appropriate layering strategy for separation of
concerns
?
How to design highly cohesive components and group them within
layers
?
How to determine when loose coupling is appropriate between
components within a layer
|
Data Access
|
?
How to manage database connections
?
How to handle exceptions
?
How to improve performance
?
How to handle binary large objects (BLOBs)
|
Exception Management
|
?
How to handle exceptions
?
How to log exceptions
?
How to provide notification when required
|
Logging and
Instrumentation
|
?
How to determine which information to log
?
How to make the logging configurable
?
How to determine what level of instrumentation is required
|
User Experience
|
?
How to improve task efficiency and effectiveness
?
How to improve responsiveness
?
How to improve user empowerment
?
How to improve look and feel
|
Validation
|
?
How to determine where and how to perform validation
?
How to validate for length, range, format, and type
?
How to constrain and reject input
?
How to sanitize output
|
Workflow
|
?
How to choose the appropriate workflow technology
?
How to handle concurrency issues within a workflow
?
How to handle task failure within a workflow
?
How to orchestrate processes within a workflow
|
Quality Attributes
Type
|
Quality attributes
|
System qualities
|
?
Supportability
?
Testability
|
Run-time qualities
|
?
Availability
?
Interoperability
?
Manageability
?
Performance
?
Reliability
?
Scalability
?
Security
|
Design qualities
|
?
Conceptual Integrity
?
Flexibility
?
Maintainability
?
Reusability
|
User qualities
|
?
User Experience / Usability
|
Quality Attribute Frame
Category
|
Description / questions
|
Availability
|
Availability defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period. Availability will be affected by system errors, infrastructure problems, malicious attacks, and system load.
|
Conceptual Integrity
|
Conceptual integrity defines the consistency and coherence of the overall design. This includes the way that components or modules are designed, as well as factors such as coding style and variable naming.
|
Flexibility
|
Flexibility is the ability of a system to adapt to varying environments and situations, and to cope with changes to business policies and rules. A flexible system is one that is easy to reconfigure or adapt in response to different user and system requirements.
|
Interoperability
|
Interoperability is the ability of diverse components of a system or different systems to operate successfully by exchanging information, often by using services. An interoperable system makes it easier to exchange and reuse information internally as well as externally.
|
Maintainability
|
Maintainability is the ability of a system to undergo changes to its components, services, features, and interfaces as may be required when adding or changing the functionality, fixing errors, and meeting new business requirements.
|
Manageability
|
Manageability defines how easy it is to manage the application, usually through sufficient and useful instrumentation exposed for use in monitoring systems and for debugging and performance tuning.
|
Performance
|
Performance is an indication of the responsiveness of a system to execute any action within a given time interval. It can be measured in terms of latency or throughput. Latency is the time taken to respond to any event. Throughput is the number of events that take place within given amount of time.
|
Reliability
|
Reliability is the ability of a system to remain operational over time. Reliability is measured as the probability that a system will not fail to perform its intended functions over a specified time interval.
|
Reusability
|
Reusability defines the capability for components and subsystems to be suitable for use in other applications and in other scenarios. Reusability minimizes the duplication of components and also the implementation time.
|
Scalability
|
Scalability is the ability of a system to function well when there are changes to the load or demand. Typically, the system will be able to be extended over more powerful or more numerous servers as demand and load increase.
|
Security
|
Security defines the ways that a system is protected from disclosure or loss of information, and the possibility of a successful malicious attack. A secure system aims to protect assets and prevent unauthorized modification of information.
|
Supportability
|
Supportability defines how easy it is for operators, developers, and users to understand and use the application, and how easy it is to resolve errors when the system fails to work correctly.
|
Testability
|
Testability is a measure of how easy it is to create test criteria for the system and its components, and to execute these tests to determine if the criteria are met. Good testability makes it more likely that faults in a system can be isolated in a timely and effective manner.
|
Usability
|
Usability defines how well the application meets the requirements of the user and consumer by being intuitive, easy to localize and globalize, able to provide good access for disabled users, and able to provide a good overall user experience.
|
Security Frame
Category
|
Description / questions
|
Auditing and Logging
|
Who did what and when? Auditing and logging refer to how your application records security-related events.
|
Authentication
|
Who are you? Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a username and password.
|
Authorization
|
What can you do? Authorization refers to how your application provides access controls for resources and operations.
|
Configuration Management
|
Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings protected? Configuration management refers to how your application handles these operations and issues.
|
Cryptography
|
How are you handling secrets (confidentiality)? How are you tamperproofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality and integrity.
|
Exception Management
|
When a method call in your application fails, what does your application do? How much information do you reveal? Do you return friendly information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully? Exception management refers to how you handle exceptions within your application.
|
Input and Data Validation
|
How do you know that the input your application receives is valid and safe? Input validation refers to how your application filters, scrubs, or rejects input before additional processing. Consider constraining input through entry points and encoding output through exit points. Do you trust data sources such as databases and file shares?
|
Sensitive data
|
How does your application handle sensitive data? Does your application protect confidential user and application data? Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent stores.
|
Session Management
|
How does your application handle and protect user sessions? A session refers to a session of related interactions between a user and your Web application.
|
Step 5: Candidate Solutions.
Consider the following guidelines when creating your architectural spikes:
?
Understand your key risks and adapt your design to reduce these risks.
?
Optimize your deliverables for effective and efficient communication of design information.
?
Build your architecture with flexibility and refactoring in mind. You might need to modify your architecture a number of times, so optimize around this possibility. | 
陕公网安备：61019002000258 |
隐私政策 |
网站地图