I've divided this book into three major parts . Part I introduces .NET and the elements of design and architecture necessary to begin writing truly sound applications. This includes the lower level plumbing components that most frameworks require. These "framework patterns and practices" apply to all aspects of .NET development, such as exception handling and logging. Part II outlines specific things to do and things not to do in a tier architecture, breaking the pattern classifications up into your three tiers: presentation tier, middle tier, and persistence tier . This highlights not only best practices and implementation patterns but also the more technology- agnostic architecture and design patterns. The final chapter really belongs on its own because it includes more advanced patterns covering topics such as asynchronous behavior, complex threading, and caching. These patterns are needed for many frameworks but are not considered a requirement and, thus, are given their own chapter. Many of the patterns will coincide with the established patterns of the "gang of four," adding to your design tool belt.
In Chapter 1, I will give you a brief technical rundown of XML Web services, the .NET world of object orientation, and a few pattern definitions for those new to this design approach. Throughout the book, I will introduce new .NET topics and some of the features unique to other frameworks that may affect your design and your understanding of the content. I will also begin to plant the seeds of those services supplied by .NET that will be leveraged in the more technology-focused patterns later in the book.
Part I: Building a Framework with .NET
Chapter 1 ”New Framework, New Model, New Measures
Here I take a brief look at patterns, their classifications, and applying them to the .NET framework. I'll introduce patterns for those of you who have never worked with them in the past and provide a process of how they may be applied. I will also frame what separates this development release from all others coming from Microsoft, such as the incorporation of XML Web services.
This chapter will also take a brief look at the elements of .NET that will be used to exemplify each practice presented. Although many patterns are technology-agnostic, this is not always the case for implementation and architecture patterns. Here I will briefly review those .NET elements required to grasp the more technology-specific patterns. This will also serve as a "crash course" for those new to the .NET base class library (BCL).
Finally, this chapter takes a deeper looks at patterns, their classifications, and their history. This chapter will be especially important for programmers used to more linear style (e.g., Visual Basic, Active Server Pages, etc.) who may be comfortable with component-oriented COM design but less comfortable with OO design. I'll explain what implementation patterns are and how they are different from architecture and design patterns. Here I talk about the good and the bad of .NET design, architecture, and development by presenting a set of best practices and "named" implementation patterns.
I also will provide a .NET primer along the way to acquaint those unfamiliar with the "library hieroglyphics" used in the upcoming pattern diagrams. These "primers" will be only a "tutorial thumbnail" because there is so much material better suited that will cover the background of these topics in depth.
Chapter 2 ”Framework Patterns: Exception Handling, Logging, and Tracing
Topics such as debugging, error handling, and logging will be covered in this chapter due to their general applicability and importance. This content belongs right up front in the book because I feel it is one of most important elements of a good design and a robust application overall. To begin with a design of any good framework, you can start with these practices and implementation patterns to put together the initial "plumbing" for your application. Again at this point, you should be comfortable with the .NET technology and of patterns in general. These topics overall are what I call framework patterns because they make up the backbone of the framework and are vital to any application. This includes exception handling, logging, tracing, and many other practices not categorized as presentation, middle-tier, or persistent-oriented. Although much of this code can be placed at the middle tier, much of is vital to all tiers and is categorized as such.
The principles and patterns covered in detail are:
The following specific implementation patterns will be described in detail:
This part of the book dives right into the catalog of design and architecture patterns typically (but not always) found at specific tier of an application. Some are simply new twists to old familiar patterns, whereas others are unique. Some of the patterns will be technology-agnostic and others exploit some unique framework features of .NET and, thus, are slightly more technology-specific.
Part II: Creating the Tiers of a Framework
Chapter 3 ”Presentation-Tier Patterns
At this point, you should be comfortable with .NET, Web services, and patterns. Now I delve into the implementation practices for all front-end development. This includes "thin" and "thick" client implementation practices such as screen refreshing, GUI threading, custom control display, and interface template principles. Even more advanced topics, such as asynchronous Web service invocations and client-side threading, will be discussed. If you will be working solely on middle-tier components, you are free to skip this chapter.
As you may surmise, this chapter catalogs patterns found at the presentation tier. This includes:
Chapter 4 ”Middle-Tier Patterns
In this chapter, I cover six middle-tier or "business"-tier patterns that can really be applied at any level. This catalog contains all of those patterns that are not typically considered "advanced" yet cannot be truly considered related to the tier-2 tiers, presentation or persistence (data). For those designing an architecture that must present a single point of entry, sometimes it makes sense to start here. This can also be considered an opportunity to design the distributed wrapper that will make all components of your middle-ware accessible yet secure to the outside world. Both the framework patterns and these patterns are the very first pieces I recommend be created for any architecture. These patterns, along with those from Chapter 2, provide the essential elements needed to build a truly dynamic and flexible design. These should also insulate your support from change based on user requirements in the future and allow your developers to concentrate on business rules definition and not "plumbing" problems.
The patterns covered here are:
Chapter 5 ”Persistence-Tier Patterns
Here I will focus on the persistent-tier architecture and implementation patterns. This includes database access, streaming practices, and XML schema-based I/O. Here I will get into some of .NET's most powerful XML data features and show how you can exploit them. This includes taking advantage of DataSets, XML schemas, automated data-tier code generation, dynamic data modeling, type-strong schemas, and the flexibilities of XML and how to leverage it.
The architecture patterns covered are:
Chapter 6 ”Process Patterns: Applying .NET Patterns to a Commercial Product
In this chapter, I talk about a real-world .NET commercial application called ProductX that I had the pleasure to lead in the design and architecture effort. I will provide some of the practices we applied to this financial services application and how .NET was used as the migration target technology from a traditional C++/COM-based platform. I will also describe how some of the patterns outlined in this book were applied to its implementation. During this product's development life cycle, I "ate my own dog food," so to speak, by using most of the patterns in this book in a live commercial application.
The patterns from this book that I provide a roadmap to in this commercial application are:
Chapter 7 ”Advanced Patterns
This chapter goes into those patterns I considered advanced. These can be applied at any level and are not consider essential to an application but extremely useful. When performance becomes an issue, some of these patterns can be applied, such as the addition of caching and asynchronous processing. These can be added to enhance a design but should be used in only specific scenarios and with greater caution. If any of these patterns are implemented or applied incorrectly, they will decrease their overall benefit and defeat any reason for applying them.
The advanced patterns include:
For those who are already comfortable with the .NET framework or do not wish to hear another executive retread of this .NET or of Web services, WSDL, or SOAP you can skip the following section. For those new to SOAP and how Web services work, read on.
A book is more than the authors who write it. It is a culmination of creative effort from ideas, whiteboard sessions, art work, editing, and most importantly, time. There have been many people explicitly and implicitly involved in this 18-month project. The easiest to forget are those who've contributed those intangible assets such as time and the patience to go along with it. I'd like to thank some of the people who've helped me get from that first blurry idea to design to code to content to production. Not only were people providing their own time to dedicate to the material presented here but there also were those folks who provided me with my own time to use on this project. There were those individuals like Brett Walker who allowed me the time to work on this, even when that time could have been spent elsewhere ”time that could have been used for more immediately profitable ventures . So I will thank all those individuals in "chronologically contributing order" from ideas to production.
I want to thank Paul Becker for taking the time to hear my ideas for this book and for seeing the merit of its premise . I want especially to thank John Neidhart for picking up this project at Addison, taking its ideas on trust (with little time to dig in), and reeling me in by rescoping my efforts and providing me a more practical set of deliverables. I want to thank all of the members of the production team (Kyle Howard, Marti Jones, and Patti Guerrieri) for making this first book as painless as possible.
I thank Brett Walker for allowing me to continue this book during my time spent working with him and his company. I was given the ability to synergize my efforts of designing a production application using principles in this book, and Brett provided me that perfect testing platform. Without this cooperative and synergistic effort, many of the principles in this book may have fallen into an academic pit. Brett Walker, David Mytchak, James Williams gave me the important feedback and creative inspiration for many of these patterns. My ideas would not have made it to fruition during the early months without the help of David Mytchak. Without David's thoughts and James's code, I would have never been able to go against some traditional thinking and created Chapter 5. The Poly Model was your "raw idea" coming to life in these pages.
I also want to thank all those at Microsoft who inherited this book upon my rejoining the company in early spring of 2003. Everyone at Microsoft has been so supportive of this project and has helped me refine the book's message. The material presented here has fit very nicely with Microsoft's own prescriptive branding and its own architecture principles. It just goes to show you that good design is good design, no matter how you brand it. I specifically want to thank the members of the Gulf Coast developer team at Microsoft of which I'm a member: Ed Draper, J Sawyer, Michael Lane Thomas, and John Opalko for helping me get the message out that this book existed ”and for adding it to their presentation slides at the last minute.
I want to thank my wife, Hilari. By the time this is published, we will have just returned from our honeymoon. We can now look back and enjoy the fruits of our labor. We can now appreciate all of the weekends and weeknights spent in front of my computer when she had to slip food under my door. Thanks for being patient and understanding with this project. I also want to thank my mother for all those "little favors" that saved me so much time to work on this book.
Finally, I need to thank Brian Eshelman, who saved my backside by being the major contributor of all content for Chapter 3. Those were his ideas, designs, and code. Without them, my deadline would have been in jeopardy ”thank you so much, Brian, for being a part of this book. You are a wonderful designer, developer, and friend.