Professional ASP.NET Design Patterns

Scott Millett

• Publisher: Wrox
• Year: 2010
• ISBN:
  9780470952894
• Edition: 1
• Topic: Design
• Subtopic: Webdesign

• Design patterns are time-tested solutions to recurring problems, letting the designer build programs on solutions that have already proved effective
• Provides developers with more than a dozen ASP.NET examples showing standard design patterns and how using them helpsbuild a richer understanding of ASP.NET architecture, as well as better ASP.NET applications
• Builds a solid understanding of ASP.NET architecture that can be used over and over again in many projects
• Covers ASP.NET code to implement many standard patterns including Model-View-Controller (MVC), ETL, Master-Master Snapshot, Master-Slave-Snapshot, Façade, Singleton, Factory, Single Access Point, Roles, Limited View, observer, page controller, common communication patterns, and more

Part I: Introducing Patterns and Principles

• Chapter 1: The Pattern for Successful Applications
• Chapter 2: Dissecting the Pattern’s Pattern

Chapter 1

The Pattern for Successful Applications

What’s In This Chapter?

• An introduction to the Gang of Four Design Patterns
• An overview of some common design principles and the SOLID design principles
• A description of Fowlers Enterprise Patterns

John Lennon once wrote, “There are no problems, only solutions.” Now, Mr. Lennon never, to my mind, did much in the way of ASP.NET programming; however, what he said is extremely relevant in the realm of software development and probably humanity, but that’s a whole other book. Our job as software developers involves solving problems — problems that other developers have had to solve countless times before albeit in various guises. Throughout the lifetime of object-oriented programming, a number of patterns, principles, and best practices have been discovered, named, and catalogued. With knowledge of these patterns and a common solution vocabulary, we can begin to break down complex problems, encapsulate what varies, and develop applications in a uniformed way with tried and trusted solutions.

This book is all about introducing you to design patterns, principles, and best practices that you can apply to your ASP.NET applications. By their very nature, patterns and principles are language agnostic, so the knowledge gained in this book can be applied to win forms, WPF and Silverlight applications, as well as other first-class object-oriented languages.

This chapter will cover what design patterns are, where they come from, and why it’s important to study them. Fundamental to design patterns are solid object-oriented design principles, which will be covered in this chapter in the form of Robert Martin’s S.O.L.I.D. principles. I will also introduce you to some more advanced patterns as laid out in Martin Fowler’s Patterns of Enterprise Application Architecture book.

Design Patterns Explained

Design patterns are high-level abstract solution templates. Think of them as blueprints for solutions rather than the solutions themselves. You won’t find a framework that you can simply apply to your application; instead, you will typically arrive at design patterns through refactoring your code and generalizing your problem.

Design patterns aren’t just applicable to software development; design patterns can be found in all areas of life from engineering to architecture. In fact, it was the architect Christopher Alexander who introduced the idea of patterns in 1970 to build a common vocabulary for design discussion. He wrote:

The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment and then describes the core of the solution to that problem in such a way that you can use this solution a million times over without ever doing it the same way twice.

Alexander’s comments are just as applicable to software design as they are to buildings and town planning.

Origins

The origins of the design patterns that are prevalent in software architecture today were born from the experiences and knowledge of programmers over many years of using object-oriented programming languages. A set of the most common patterns were catalogued in a book entitled Design Patterns: Elements of Reusable Object-Oriented Software, more affectionately known as the Design Patterns Bible. This book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, better known as the Gang of Four.

They collected 23 design patterns and organized them into 3 groups:

• Creational Patterns: These deal with object construction and referencing.
• Structural Patterns: These deal with the relationships between objects and how they interact with each other to form larger complex objects.
• Behavioral Patterns: These deal with the communication between objects, especially in terms of responsibility and algorithms.

Each pattern is presented in a template so readers can learn how to decipher and apply the pattern. We will be covering the practical knowledge necessary to use a design pattern template in Chapter 2 along with a brief overview of each pattern that we will be looking at in the rest of this book.

Necessity

Patterns are essential to software design and development. They enable the expression of intent through a shared vocabulary when problem solving at the design stage as well as within the source code. Patterns promote the use of good object-oriented software design, as they are built around solid object-oriented design principles.

Patterns are an effective way to describe solutions to complex problems. With solid knowledge of design patterns, you can communicate quickly and easily with other members of a team without having to be concerned with the low-level implementation details.

Patterns are language agnostic; therefore, they are transferable over other object-oriented languages. The knowledge you gain through learning patterns will serve you in any first-class object-oriented language you decide to program in.

Usefulness

The useful and ultimate value of design patterns lies in the fact that they are tried and tested solutions, which gives confidence in their effectiveness. If you are an experienced developer and have been programming in .NET or another object-oriented language for a number of years, you might find that you are already using some of the design patterns mentioned in the Gang of Four book. However, by being able to identify the patterns you are using, you can communicate far more effectively with other developers who, with an understanding of the patterns, will understand the structure of your solution.

Design patterns are all about the reuse of solutions. All problems are not equal, of course, but if you can break down a problem and find the similarities with problems that have been solved before, you can then apply those solutions. After decades of object-oriented programming, most of the problems you’ll encounter will have been solved countless times before, and there will be a pattern available to assist in your solution implementation. Even if you believe your problem to be unique, by breaking it down to its root elements, you should be able to generalize it enough to find an appropriate solution.

The name of the design pattern is useful because it reflects its behavior and purpose and provides a common vocabulary in solution brainstorming. It is far easier to talk in terms of a pattern name than in detail about how an implementation of it would work.

What They Are Not

Design patterns are no silver bullet. You have to fully understand your problem, generalize it, and then apply a pattern applicable to it. However, not all problems require a design pattern. It’s true that design patterns can help make complex problems simple, but they can also make simple problems complex.

After reading a patterns book, many developers fall into the trap of trying to apply patterns to everything they do, thus achieving quite the opposite of what patterns are all about — making things simple. The better way to apply patterns, as stated before, is by identifying the fundamental problem you are trying to solve and looking for a solution that fits it. This book will help with the identification of when and how to use patterns and goes on to cover the implementation from an ASP.NET point of view.

You don’t always have to use design patterns. If you have arrived at a solution to a problem that is simple but not simplistic and is clear and maintainable, don’t beat yourself up if it doesn’t fit into one of the 23 Gang of Four design patterns. Otherwise, you will overcomplicate your design.

This talk of patterns might seem rather vague at the moment, but as you progress through the book, you will learn about the types of problems each pattern was designed to solve and work through implementations of these patterns in ASP.NET. With this knowledge, you can then apply the patterns to your applications.

Design Principles

Design principles form the foundations that design patterns are built upon. They are more fundamental than design patterns. When you follow proven design principles, your code base becomes infinitely more flexible and adaptable to change, as well as more maintainable. I will briefly introduce you to some of the more widely known design principles and a series of principles known as the S.O.L.I.D. principles. Later in the book we will look at these principles more deeply and implement them and best practices in ASP.NET.

Common Design Principles

There are a number of common design principles that, like design patterns, have become best practice over the years and helped to form a foundation onto which enterprise-level and maintainable software can be built. The following sections preview some of the more widely known principles.

Keep It Simple Stupid (KISS)

An all-too-common issue in software programming is the need to overcomplicate a solution. The goal of the KISS principle is concerned with the need to keep code simple but not simplistic, thus avoiding any unnecessary complexities.

Don’t Repeat Yourself (DRY)

The DRY principle aims to avoiding repetition of any part of a system by abstracting out things that are common and placing those things in a single location. This principle is not only concerned with code but any logic that is duplicated in a system; ultimately there should only be one representation for every piece of knowledge in a system.

Tell, Don’t Ask

The Tell, Don’t Ask principle is closely aligned with encapsulation and the assigning of responsibilities to their correct classes. The principle states that you should to tell objects what actions you want them to perform rather than asking questions about the state of the object and then making a decision yourself on what action you want to perform. This helps to align the responsibilities and avoid tight coupling between classes.

You Ain’t Gonna Need It (YAGNI)

The YAGNI principle refers to the need to only include functionality that is necessary for the application and put off any temptation to add other features that you may think you need. A design methodology that adheres to YAGNI is test-driven development (TDD). TDD is all about writing tests that prove the functionality of a system and then writing only the code to get the test to pass. TDD is discussed a little later in this chapter.

Separation of Concerns (SoC)

SoC is the process of dissecting a piece of software into distinct features that encapsulate unique behavior and data that can be used by other classes. Generally, a concern represents a feature or behavior of a class. The act of separating a program into discrete responsibilities significantly increases code reuse, maintenance, and testability.

The remainder of this book refers back to these principles so you can see how they are implemented and help form clean and maintainable object-oriented systems. The next group of design principles you will look at were collected together under the grouping of the S.O.L.I.D. design principles.

The S.O.L.I.D. Design Principles

The S.O.L.I.D. design principles are a collection of best practices for object-oriented design. All of the Gang of Four design patterns adhere to these principles in one form or another. Th...