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 FrameworkTM 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.