Book Layout

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:

Exception Handling ” Structured error handling with .NET

Exception Logging ” Event logging and instrumentation practices

Exception Chaining ” "Bubbling up" your errors from tier to tier

Building a Base Exception Class ” Creating a foundation for your error handling

Tracing and Trace Listening ” Centralizing and simplifying your instrumentation

Error and Call Stacks ” Presenting and enriching your presented errors

When, Where, and How to Log ” The heuristics of error handling in .NET

SOAP Exceptions and SOAP Faults ” Errors in the Web services environment

Interop Exception Handling ” Errors in the distributed EAI environment

The following specific implementation patterns will be described in detail:

Remote Tracer ” Tracing and error handling across machine boundaries

Custom Soap Exception Handler ” Error handling in the Web services environment

System Exception Wrapper ” Handling .NET system exceptions

Soap Fault Builder ” Preparing errors to be viewed by Web service clients

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:

Notifying Thread Manager ” Create a thread and notify a Windows form

Pollable Thread Manager ” Create a thread and periodically check status

MultiSync Thread Manager ” Combine Notifying and Pollable Thread Managers

Error Cross-Reference Generator ” Error ID generator used during exception handling

Web Form Template ” Base template class for a quick interface layouts

Stunt Driver ” Generic interface for testing a component

Dynamic Assembly Loader ” Dynamic loading and caching driver

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:

Chained Service Factory ” Creating a single entry point for Web services

Unchained Service Factory ” A late-bound single entry point for Web services

Product Manager ” Handling unmanaged code in a managed way

Service Fa §ade ” Delegating complex logic from Web services

Abstract Packet ” Handling and passing complex parameter sets

Packet Translator ” Translating those complex parameters sets

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:

Poly Model ” Providing a "dynamic physical data model" using XML schemas

Poly Model Factory ” Applying Factory Methods to Poly Models

Schema Field ” Persisting schemas, retrieving schemas, and schema management

Schema Indexer ” Building dynamic indexes using schema and Poly Models

Abstract Schema ” Applying the Abstract Packet pattern in a world of XML schemas

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:

Poly Model ” Applying the Poly Model composite pattern and integrating it with a product database

Unchained Service Factory ” A late-bound single entry point for the Web services used by ProductX for all external access

Product Manager ” Providing the business framework by which all financial components were managed in the Commercial Framework.

Service Fa §ade ” Delegating complex logic from Web services and defining the framework feature set for financial services

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:

Abstract Cache ” Abstracted caching framework using cache object

Web Service Interface ” Interface-based Web services

Loosely Coupled Transactor ” Abstracted asynchronous business transactions

LCT Server ” Server-based Loosely Coupled Transactor

LCT Client ” Client-based Loosely Coupled Transactor

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.

.NET Patterns. Architecture, Design, and Process
.NET Patterns: Architecture, Design, and Process
ISBN: 0321130022
EAN: 2147483647
Year: 2003
Pages: 70 © 2008-2017.
If you may any questions please contact us: