DESIGN PATTERNS

Singleton

Rationale and Motivation

The singleton pattern applies to the many situations in which there needs to be a single instance of a class, a single object. It is often left up to the programmer to insure that the important consideration in implementing this pattern is how to make this single instance easily accessible by many other objects.

Advantages

What are the advantages to using this pattern?

Single instance is controlled absolutely. When implemented as the pattern recommends, the class will have direct control over how many instances can be created. This is in contrast to making the programmer responsible for insuring that there is only one instance.

This pattern is easily extensible to allow a controlled number of "singleton" objects to be created. The most important modification needed to accomplish this change is in the operator that has control over access to the instances. In this case, the Instance() function would need to be changed.

DESIGN PATTERNS

Facade

Rationale and Motivation

The facade pattern can make the task of accessing a large number of modules much simpler by providing an additional interface layer. When designing good programs, programmers usually attempt to avoid excess coupling between module/classes. Using this pattern helps to simplify much of the interfacing that makes large amounts of coupling complex to use and difficult to understand. In a nutshell, this is accomplished by creating a small collection of classes that have a single class that is used to access them, the facade.

Advantages/Disadvantages

As stated before, the primary advantage to using the facade is the make the interfacing between many modules or classes more manageable. One possible disadvantage to this pattern is that you may lose some functionality contained in the lower level of classes, but this depends on how the facade was designed.

Examples

Imagine that you need to write some program that needs to represent a building as rooms that can be manipulated. Manipulated as in interacting with objects in the room to change their state. The client that has ordered this program has determined that there will only be a need for a finite number of objects possible in each room, and a finite number of operations that can be performed on each of them.

You, as the program architect, have decided that the facade pattern will be an excellent way to keep the amount of interfacing low, considering the number of possible objects in each room, and the actions that the client has specified.

A sample action for a room is to "prepare it for a presentation". You have decided that this will be part of your facade interface since it deals with a large number of classes, but does not really need to bother the programmer with interacting with each of them when a room needs to be prepared. Here is how that facade might be organised.

Consider the sheer simplicity from the client's side of the problem. A less thought out design may have looked like this, making lots of interaction by the client necessary.

Food for thought...

The compilers that we use everyday to process the computer code that we have written is a prime example of the facade pattern in action. What other examples are there that you can think of?

Design Patterns in Practice: (From Wikipedia)

Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

In order to achieve flexibility, design patterns usually introduce additional levels of indirection, which in some cases may complicate the resulting designs and hurt application performance.

By definition, a pattern must be programmed anew into each application that uses it. Since some authors see this as a step backward from software reuse as provided by components, researchers have worked to turn patterns into components. Meyer and Arnout claim a two-thirds success rate in componentizing the best-known patterns.^[4]

Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.

(From doFactory)

.NET 3.5, WCF, WPF, and LINQ

With the release of .NET 3.5, Microsoft introduced several new technologies, including WPF, WCF, and LINQ. As a .NET developer you know it takes time and effort to study and internalize these new platforms. And, it takes even more time before you are confident in applying and integrating these into your own projects.

Design Pattern Framework 3.5 is designed to shorten the learning curve for these platforms. It includes a comprehensive set of proven pattern and practices that are presented in the form of real-world code (built on WCF, WPF, LINQ) in our Patterns in Action reference application. With this resource on your side you will become confident and productive quickly and effectively.

It's like learning to walk: you fall and get up many times. Patterns in Action shortens this process and soon you'll be running like a pro making great strides in your new .NET 3.5 pattern lifestyle!

Using patterns to build a robust 3-tier architecture

Many .NET applications do not benefit from a robust 3-tier architecture. They are built on a simple 2-tier client/server model in which all code (UI, business logic, and data access) is placed at one location: the code behind pages.

Indeed, the initial development cycle may be shorter, but in the long run you'll find that these applications do not evolve easily with changing business needs. They are hard to maintain, nearly impossible to change, difficult to integrate (expose as a Web Services for example), and they do not scale very well (for when your website becomes an instant success!).

You may be wondering, how do I build a pattern-based, 3-tier application?
We're glad you asked. Here is how it's done in Patterns in Action:

In a 3-tier model each tier corresponds directly to one of the three elements needed in an architecture: interaction, manipulation, and storage. The three tiers or layers are:

• Presentation layer — handles external interaction with the user
• Business layer — manipulates the information required by the user
• Database layer — stores the data handled by the system

Now, 3-tier architectures are widely accepted as a high-level best practice approach. However, a few details need to be resolved. For example, how is each tier built and and how do the tiers communicate with each other?

Below is a cross-section that shows some of the technologies used and the communication between the layers. Notice the prominent role that WCF plays. It is a single point of entry (Cloud Facade Pattern) into the application services.

The right-hand-side shows some of the key design patterns used in the reference application. Clearly, patterns play an integral role throughout the entire 3-tier architecture.

3-tier cross-section:

Here are some details on the tiers and their relationships:

The PL: The concern of the Presentation Layer (PL) is to present information in a consistent and easy-to-understand manner to the end-user. Patterns in Action includes fully functional implementations of three UI platforms: ASP.NET, Windows Forms and WPF (Windows Presentation Foundation).

From PL to WCF: Each of the 3 UI platforms consume the exact same services hosted under WCF. This service-oriented model is an implementation of the Cloud Facade Design Pattern. Applications designed this way have the ability to expose their Services (Web or otherwise) with no extra work (other than configuring the WCF host). WCF is truly a powerful new platform!

From WCF to BL: The WCF Service Layer receives messages from the PL. It interprets the message, unpacks the Data Transfer Objects, and orchestrates and coordinates the interaction between Business Objects and Data Access Objects. The Services Layer is also the place where authorization, authentication, data validation, and database transactions are implemented.

The BL: In the Business Layer (BL) you'll find Business objects, such as, Product, Customer, and Order. Business Objects encapsulate business logic in the form of business rules. Business Objects themselves have no knowledge about databases or data persistence, which is handled by the DL.

From BL to DL: In fact, Business Objects do not directly interact with the Data Layer (DL).You don't ask a Product business object to save itself and there are no Save or Load methods on the Business Objects themselves. Instead, persistence is handled by dedicated Data Access Objects (another Enterprise Pattern) that extract data from the Business Objects and subsequently store it in the database.

The DL: The Data Layer (DL) handles the persistence of Business Objects. Patterns in Action offers two different technologies: ADO.NET and LINQ-to-SQL. In web.config you indicate which one to use. ADO.NET implements a 'data provider factory' which uses an abstract factory pattern and returns database specific singleton factories. This example shows that design patterns frequently work together with other patterns. When using LINQ-to-SQL you will see that LINQ generated Entities are mapped to Business Objects.

Even if you do not purchase the Design Pattern Framework^TM we'd like you to walk away with the following important observation:

Have you noticed that there are no direct interactions between the PL and the BL or DL? In other words, the UI only interacts with the application via the WCF Service Layer. This is by design. The reason is that security, data validation, and transactions are managed at the Service Layer. The UI is not allowed to bypass these important functions. Therefore, all communication with the application must go through this single point-of-entry (Cloud Facade) which is hosted under WCF.

Gang of Four Design Patterns

Patterns in Action incorporates all of the frequently used Gang of Four patterns, such as, Facade, Singleton, Abstract Factory, Observer, and Proxy. Here are some details on how these patterns are used in the application:

Facade

The Facade design pattern plays a key role in the application. Not only does it enhance and simplify the design of the application, it also makes it easy to be integrated into a larger WCF based SOA (Service Oriented Architecture). The WCF services are exposed as a single-point-of-entry for any platform and any application that consumes its services on the cloud. This is why it has been named Cloud Facade.

With the Facade pattern, the code-behind is often as simple as this: (note: the controller internally invokes the Facade - or Service Layer):

CustomerController ctrl = new CustomerController();

DataViewCustomers.DataSource = ctrl.GetCustomers();
DataViewCustomers.DataBind();

Composite

The ASP.NET menu system is designed as a hierarchy with parent and child nodes. This self-referencing tree structure is implemented using the Composite design pattern.

Observer

Error logging and tracing are implemented with the help of the Observer pattern. Observer classes register themselves with the Logger and listen for Log events. In fact, two design patterns are at play here as the Logger class is a Singleton also.

Strategy

Patterns in Action comes with a fully functional e-commerce shopping cart. Items can be added, removed, and recalculated in the cart. The Strategy pattern is used to swap out different strategies for shipping charges (and can easily be extended to include tax and insurance computations, if necessary).

Abstract Factory + Singleton

The Abstract Factory pattern solves the problem of accessing different databases. Database specific factories are created which themselves are Singletons. These factories allow you to change databases simply by changing an entry in web.config. Databases supported include: MS Access, SQL Express, and SQL Server.

Proxy

Proxies typically are surrogate objects that represent external resources that are slow or not guaranteed to be always available. In Pattern in Action we demonstrate database proxies and WCF client proxies. These are 'stand-ins' or proxies for the real objects.