Cheat Sheet: patterns & practices Pattern Catalog

J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat

Composite Application Guidance for WPF

Category Patterns
Modularity Service Locator
Testability Patterns Inversion of Control
Dependency Injection
Separated Presentation
Supervising Controller
Presentation Model

Data Patterns

Category Patterns
Data Movement Patterns Data Replication
Master-Master Replication
Master-Subordinate Replication
Master-Master Row-Level Synchronization
Master-Subordinate Snapshot Replication
Capture Transaction Details
Master-Subordinate Transactional Incremental Replication
Master-Subordinate Cascading Replication
Pattlets Maintain Data Copies
Application-Managed Data Copies
Extract-Transform-Load (ETL)
Topologies for Data Copies

Enterprise Solution Patterns

Category Patterns
Deployment Patterns Deployment Plan
Layered Application
Three-Layered Services Application
Tiered Distribution
Three-Tiered Distribution
Distributed Systems Broker
Data Transfer Object
Singleton
Performance and Reliability Server Clustering
Load-Balanced Cluster
Failover Cluster
Services Patterns Service Interface
Service Gateway
Web Presentation Patterns Model-View-Controller
Page Controller
Front Controller
Intercepting Filter
Page Cache
Observer
Pattlets Abstract Factory
Adapter
Application Controller
Application Server
Assembler
Bound Data Control
Bridge
Command(s)
Decorator
Façade
Four-Tiered Distribution
Gateway
Layer Supertype
Layers; Mapper
Mediator
MonoState
Observer
Naming Service
Page Data Caching
Page Fragment Caching
Presentation-Abstraction-Controller
Remote Façade
Server Farm
Special Case
Strategy
Table Data Gateway
Table Module
Template Method

Integration Patterns

Category Patterns
Integration Layer Entity Aggregation
Process Integration
Portal Integration
Integration Topologies Message Broker
Message Bus
Publish / Subscribe
System Connections Data Integration
Functional Integration
Service-Oriented Integration
Presentation Integration
Additional Integration Patterns Pipes and Filters
Gateway

Web Services Security Patterns

Category Pattern
Authentication Brokered Authentication
Brokered Authentication: Kerberos
Brokered Authentication: X509 PKI
Brokered Authentication: STS
Direct Authentication
Authorization Protocol Transition with Constrained Delegation
Trusted Subsystem
Exception Management Exception Shielding
Message Encryption Data Confidentiality
Message Replay Detection Message Replay Detection
Message Signing Data Origin Authentication
Message Validation Message Validator
Deployment Perimeter Service Router

Pattern Summaries

Composite Application Guidance for WPF

Modularity
Testability
  • Dependency Injection. Do not instantiate the dependencies explicitly in your class. Instead, declaratively express dependencies in your class definition. Use a Builder object to obtain valid instances of your object’s dependencies and pass them to your object during the object’s creation and/or initialization. See http://msdn.microsoft.com/en-us/library/cc707845.aspx
  • Inversion of Control. Delegate the function of selecting a concrete implementation type for the classes’ dependencies to an external component or source. See http://msdn.microsoft.com/en-us/library/cc707904.aspx
  • Presentation Model. Separate the responsibilities for the visual display and the user interface (UI) state and behavior into different classes named, respectively, the view and the presentation model. The view class manages the controls on the UI, and the presentation model class acts as a façade on the model with UI-specific state and behavior, by encapsulating the access to the model and providing a public interface that is easy to consume from the view (for example, using data binding). See http://msdn.microsoft.com/en-us/library/cc707885.aspx
  • Separated Presentation. Separate the presentation logic from the business logic into different artifacts. The Separated Presentation pattern can be implemented in multiple ways, such as Supervising Controller or Presentation Model,** etc. See http://msdn.microsoft.com/en-us/library/cc707862.aspx
  • Supervising Controller. Separate the responsibilities for the visual display and the event-handling behavior into different classes named, respectively, the view and the presenter. The view class manages the controls on the UI and forwards user events to a presenter class. The presenter contains the logic to respond to the events, update the model (business logic and data of the application), and, in turn, manipulate the state of the view. See http://msdn.microsoft.com/en-us/library/cc707873.aspx

Data Movement Patterns

  • Data Replication. Build on the data movement building block by adding refinements that are appropriate to replication. See http://msdn.microsoft.com/en-us/library/ms978671.aspx .
  • Master-Master Replication. Copy data from the source to the target and detect and resolve any update conflicts that have occurred since the last replication (due to changes to the same data on the source and target). The solution consists of a two replication links between the source and the target in opposite directions. Both replication links transmit the same replication set in both directions. Such a pair of replication links is referred to as related links in the more detailed patterns. See http://msdn.microsoft.com/en-us/library/ms978735.aspx
  • Master-Subordinate Replication. Copy data from the source to the target without regard to updates that may have occurred to the replication set at the target since the last replication. See http://msdn.microsoft.com/en-us/library/ms978740.aspx
  • Master-Master Row-Level Synchronization. Create a pair of related replication links between the source and target. Additionally, create a synchronization controller to manage the synchronization and connect the links. This solution describes the function of one of these replication links. The other replication link behaves the same way, but in the opposite direction. To synchronize more than two copies of the replication set, create the appropriate replication link pair for each additional copy. See http://msdn.microsoft.com/en-us/library/ms998434.aspx
  • Master-Subordinate Snapshot Replication. Make a copy of the source replication set at a specific time (this is known as a snapshot), replicate it to the target, and overwrite the target data. In this way, any changes that might have occurred to the target replication set are replaced by the new source replication set. See http://msdn.microsoft.com/en-us/library/ms998430.aspx
  • Capture Transaction Details. Create additional database objects, such as triggers and (shadow) tables, and record changes of all tables belonging to the replication set. See http://msdn.microsoft.com/en-us/library/ms978709.aspx
  • Master-Subordinate Transactional Incremental Replication. Acquire the information about committed transactions from the source and replay the transactions in the correct sequence when they are written to the target. See http://msdn.microsoft.com/en-us/library/ms998441.aspx
  • Master-Subordinate Cascading Replication. Increase the number of replication links between the source and target by adding one or more intermediary targets between the original source and the end target databases. These intermediaries are data stores that take a replication set from the source, and thus act as a target in a first replication link. They then act as sources to move the data to the next replication link and so on until they reach the cascade end targets (CETs). See http://msdn.microsoft.com/en-us/library/ms978712.aspx

Enterprise Solution Patterns

Deployment Patterns
  • Deployment Plan. Create a deployment plan that describes which tier each of the application’s components will be deployed to. While assigning components to tiers, if it is found that a tier is not a good match for a component, determine the cost and benefits of modifying the component to better work with the infrastructure, or of modifying the infrastructure to better suit the component. See http://msdn.microsoft.com/en-us/library/ms978676.aspx
  • Layered Application. Separate the components of your solution into layers. The components in each layer should be cohesive and at roughly the same level of abstraction. Each layer should be loosely coupled to the layers underneath. See http://msdn.microsoft.com/en-us/library/ms978678.aspx
  • Three-Layered Services Application.** Base your layered architecture on three layers: the presentation, business, and data layers. This pattern presents an overview of the responsibilities of each layer and the components that compose each layer. See http://msdn.microsoft.com/en-us/library/ms978689.aspx
  • Tiered Distribution. Structure your servers and client computers into a set of physical tiers and distribute your application components appropriately to specific tiers. See http://msdn.microsoft.com/en-us/library/ms978701.aspx
  • Three-Tiered Distribution. Structure your application around three physical tiers: the client, application, and database tiers. See http://msdn.microsoft.com/en-us/library/ms978694.aspx
Distributed Systems
  • Broker. Use the Broker pattern to hide the implementation details of remote service invocation by encapsulating them into a layer other than the business component itself. See http://msdn.microsoft.com/en-us/library/ms978706.aspx
  • Data Transfer Object. Create a data transfer object (DTO) that holds all data that is required for the remote call. Modify the remote method signature to accept the DTO as the single parameter and to return a single DTO parameter to the client. After the calling application receives the DTO and stores it as a local object, the application can make a series of individual procedure calls to the DTO without incurring the overhead of remote calls. See http://msdn.microsoft.com/en-us/library/ms978717.aspx
  • Singleton. Singleton provides a global, single instance by making the class create a single instance of itself, allowing other objects to access this instance through a globally accessible class method that returns a reference to the instance. Additionally declare the class constructor as private so that no other object can create a new instance. See http://msdn.microsoft.com/en-us/library/ms998426.aspx
Performance and Reliability
  • Server Clustering. Design your application infrastructure so that your servers appear to users and applications as virtual unified computing resources. One way to achieve this virtualization is by using a server cluster. A server cluster is the combination of two or more servers that are interconnected to appear as one, thus creating a virtual resource that enhances availability, scalability, or both. See http://msdn.microsoft.com/en-us/library/ms998414.aspx
  • Load-Balanced Cluster. Install your service or application onto multiple servers that are configured to share the workload. This type of configuration is a load-balanced cluster. Load balancing scales the performance of server-based programs, such as a Web server, by distributing client requests across multiple servers. Load-balancing technologies, commonly referred to as load balancers, receive incoming requests and redirect them to a specific host if necessary. The load-balanced hosts concurrently respond to different client requests, even multiple requests from the same client. See http://msdn.microsoft.com/en-us/library/ms978730.aspx
  • Failover Cluster. Install your application or service on multiple servers that are configured to take over for one another when a failure occurs. The process of one server taking over for a failed server is commonly known as failover. A failover cluster is a set of servers that are configured so that if one server becomes unavailable, another server automatically takes over for the failed server and continues processing. Each server in the cluster has at least one other server in the cluster identified as its standby server. See http://msdn.microsoft.com/en-us/library/ms978720.aspx
Services Patterns
  • Service Interface. Design your application as a collection of software services, each with a service interface through which consumers of the application can interact with the service. See http://msdn.microsoft.com/en-us/library/ms998421.aspx
  • Service Gateway. Encapsulate the code that implements the consumer portion of the contract into its own Service Gateway component. Service gateways play a similar role when accessing services as data access components do for access to the application’s database. They act as proxies to other services, encapsulating the details of connecting to the source and performing any necessary translation. See http://msdn.microsoft.com/en-us/library/ms998420.aspx
Web Presentation Patterns
  • Model-View-Controller. The Model-View-Controller (MVC) pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes. The Model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the View), and responds to instructions to change state (usually from the Controller). The View manages the display of information. The Controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate. See http://msdn.microsoft.com/en-us/library/ms978748.aspx
  • Page Controller. Use the Page Controller pattern to accept input from the page request, invoke the requested actions on the model, and determine the correct view to use for the resulting page. Separate the dispatching logic from any view-related code. Where appropriate, create a common base class for all page controllers to avoid code duplication and increase consistency and testability. See http://msdn.microsoft.com/en-us/library/ms978764.aspx
  • Front Controller. The Front Controller pattern solves the decentralization problem present in Page Controller by channeling all requests through a single controller. The controller itself is usually implemented in two parts: a handler and a hierarchy of commands. The handler receives the HTTP Post or Get request from the Web server and retrieves relevant parameters from the request. The handler uses the parameters from the request first to choose the correct command and then to transfer control to the command for processing. The commands themselves are also part of the controller. The commands represent the specific actions as described in the Command pattern. See http://msdn.microsoft.com/en-us/library/ms978723.aspx
  • Intercepting Filter. Use the Intercepting Filter pattern to create a chain of composable filters to implement common pre-processing and post-processing tasks during a Web page request. See http://msdn.microsoft.com/en-us/library/ms978727.aspx
  • Page Cache. Use a page cache for dynamic Web pages that are accessed frequently but change less often. See http://msdn.microsoft.com/en-us/library/ms978759.aspx
  • Observer. Use the Observer pattern to maintain a list of interested dependents (observers) in a separate object (the subject). Have all individual observers implement a common Observer interface to eliminate direct dependencies between the subject and the dependent objects. See http://msdn.microsoft.com/en-us/library/ms978753.aspx

Integration Patterns

Integration Layer
  • Entity Aggregation. Introduce an Entity Aggregation layer that provides a logical representation of the entities at an enterprise level, with physical connections that support the access and that update to their respective instances in back-end repositories. See http://msdn.microsoft.com/en-us/library/ms978573.aspx
  • Process Integration. Define a business process model that describes the individual steps that make up the complex business function. Create a separate process manager component that can interpret multiple concurrent instances of this model and that can interact with the existing applications to perform the individual steps of the process. See http://msdn.microsoft.com/en-us/library/ms978592.aspx
  • Portal Integration. Create a portal application that displays the information retrieved from multiple applications in a unified UI. The user can then perform the required tasks based on the information displayed in this portal. See http://msdn.microsoft.com/en-us/library/ms978585.aspx
Integration Topologies
  • Message Broker. Extend the integration solution by using the Message Broker pattern. A message broker is a physical component that handles the communication between applications. Instead of communicating with each other, applications communicate only with the message broker. An application sends a message to the message broker, providing the logical name of the receivers. The message broker looks up applications registered under the logical name and then passes the message to them. See http://msdn.microsoft.com/en-us/library/ms978579.aspx
  • Message Bus. Connect all applications through a logical component known as a message bus. A message bus specializes in transporting messages between applications. A message bus contains three key elements: a set of agreed-upon message schemas, a set of common command messages, and a shared infrastructure for sending bus messages to recipients. See http://msdn.microsoft.com/en-us/library/ms978583.aspx
  • Publish/Subscribe. Extend the communication infrastructure by creating topics or by dynamically inspecting message content. Enable listening applications to subscribe to specific messages. Create a mechanism that sends messages to all interested subscribers. See http://msdn.microsoft.com/en-us/library/ms978603.aspx
System Connections
  • Data Integration. Integrate applications at the logical data layer by allowing the data in one application (the source) to be accessed by other applications (the target). See http://msdn.microsoft.com/en-us/library/ms978572.aspx
  • Functional Integration. Integrate applications at the business logic layer by allowing the business function in one application (the source) to be accessed by other applications (the target). See http://msdn.microsoft.com/en-us/library/ms978578.aspx
  • Service-Oriented Integration. To integrate applications at the business logic layer, enable systems to consume and provide Extensible Markup Language (XML)-based Web services. Use Web Services Description Language (WSDL) contracts to describe the interfaces to these systems. Ensure interoperability by making your implementation compliant with the Web Services (WS-*) family of specifications. See http://msdn.microsoft.com/en-us/library/ms978594.aspx
  • Presentation Integration. Access the application’s functionality through the UI by simulating a user’s input and by reading data from the screen display. See http://msdn.microsoft.com/en-us/library/ms978588.aspx

Web Service Services Security Patterns

Authentication
  • Brokered Authentication. The Web service validates the credentials presented by the client, without the need for a direct relationship between the two parties. An authentication broker that both parties trust independently issues a security token to the client. The client can then present credentials, including the security token, to the Web service. See http://msdn2.microsoft.com/en-us/library/aa480560.aspx
  • Brokered Authentication: Kerberos. Use the Kerberos protocol to broker authentication between clients and Web services. See http://msdn2.microsoft.com/en-us/library/aa480562.aspx
  • Brokered Authentication: X509 PKI. Use brokered authentication with X.509 certificates issued by a certificate authority (CA) in a public key infrastructure (PKI) to verify the credentials presented by the requesting application. See http://msdn2.microsoft.com/en-us/library/aa480565.aspx
  • Brokered Authentication: STS. Use brokered authentication with a security token issued by a Security Token Service (STS). The STS is trusted by both the client and the Web service to provide interoperable security tokens. See http://msdn2.microsoft.com/en-us/library/aa480563.aspx
  • Direct Authentication. The Web service acts as an authentication service to validate credentials from the client. The credentials, which include proof-of-possession that is based on shared secrets, are verified against an identity store. See http://msdn.microsoft.com/en-us/library/aa480566.aspx
Authorization
  • Protocol Transition with Constrained Delegation. Use the Kerberos protocol extensions in Microsoft® Windows Server®. The extensions require the user ID but not the password. You still need to establish trust between the client application and the Web service; however, the application is not required to store or send passwords. See http://msdn.microsoft.com/en-us/library/aa480585.aspx
  • Trusted Subsystem. The Web service acts as a trusted subsystem to access additional resources. It uses its own credentials instead of the user’s credentials to access the resource. See http://msdn2.microsoft.com/en-us/library/aa480587.aspx
Exception Management
  • Exception Shielding. Sanitize unsafe exceptions by replacing them with exceptions that are safe by design. Return only those exceptions to the client that have been sanitized, or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web service’s inner workings. See http://msdn2.microsoft.com/en-us/library/aa480591.aspx
Message Encryption
  • Data Confidentiality. Use encryption to protect sensitive data that is contained in a message. Unencrypted data, which is known as plaintext, is converted to encrypted data, which is known as cipher-text. Data is encrypted with an algorithm and a cryptographic key. Cipher-text is then converted back to plaintext at its destination. See http://msdn.microsoft.com/en-us/library/aa480570.aspx
Message Replay Detection
Message Signing
  • Data Origin Authentication. Use data origin authentication, which enables the recipient to verify that messages have not been tampered with in transit (data integrity) and that they originate from the expected sender (authenticity). See http://msdn2.microsoft.com/en-us/library/aa480571.aspx
Message Validation
  • Message Validator. The message validation logic enforces a well-defined policy that specifies which parts of a request message are required for the service to successfully process it. It validates the XML message payloads against an XML schema (XSD) to ensure that they are well-formed and consistent with what the service expects to process. The validation logic also measures the messages against certain criteria by examining the message size, the message content, and the character sets that are used. Any message that does not meet the criteria is rejected. See http://msdn2.microsoft.com/en-us/library/aa480600.aspx
Deployment
  • Perimeter Service Router. Design a Web service intermediary that acts as a perimeter service router. The perimeter service router provides an external interface on the perimeter network for internal Web services. It accepts messages from external applications and routes them to the appropriate Web service on the private network. See http://msdn2.microsoft.com/en-us/library/aa480606.aspx

Additional Resources

Last edited Dec 19, 2008 at 9:02 PM by prashantbansode, version 2

Comments

No comments yet.