Wrox Professional C - Hash Design Patterns Applied PDF

What you need to use this book
The following is the list of recommended system requirements for running the code in this book:
❑ Windows 2000 Professional, Server or Advanced Server Edition; or Windows XP

Professional Edition
❑ The .NET Framework SDK
❑ Visual Studio .NET Professional Edition or higher (for Chapters 1-4)
❑ SQL Server 7.0 or 2000 (for Chapters 2 and 3)
❑ MSMQ (for Chapter 3) and IIS 5.0 (for Chapters 2 and 4); both are shipped with the operating
systems listed above
This book assumes the following knowledge:
❑ Familiarity with the C# language structure and syntax, and therefore a basic understanding of
the principles of object-oriented programming (OOP)
❑ Good working knowledge of the .NET Framework
❑ A grasp of the Visual Studio .NET IDE
Summary of Contents
Introduction 1
Chapter 1: Introduction to Design Patterns 9
Chapter 2: Design Patterns in the Data Tier 67
Chapter 3: Design Patterns in the Middle Tier 117
Chapter 4: Design Patterns in the Presentation Tier 177
Chapter 5: Between the Tiers: Design Patterns and .NET Remoting 257
Chapter 6: What Next? 299
Appendix A: UML Primer 309
Index 339
Design Patterns in the Middle Tier
Design patterns and the middle tier were made for each other. Why? Think of it this way. The very
nature of the middle tier is to execute business rules. Business rules change as often and quickly as
businesses change. Design patterns exist to encapsulate variability and change. When we put these three
assertions together, the conclusion is hard to ignore – design patterns can help developers manage those
never-ending changes to a middle tier application.
In this chapter, we will build an application that processes orders. To help us get the job done we will
use two types of patterns:
❑ The first type is the now-familiar design pattern that has been best illustrated using UML class
diagrams. In fact, our application will utilize some of the basic GoF patterns that we discussed
earlier in the book. But, unlike most instances of design patterns that we have talked about so
far, here we will use them in combination to enhance our solution. We will use the Decorator
pattern to manage the overall processing of orders; but hiding underneath it will be the
Façade and Strategy patterns.
❑ The second type of pattern we will see is one that constitutes a common architectural approach
to a common problem. Our application supports a business-to-business web-based presentation
tier – a requirement that demands performance and reliability. Fortunately, developers have
already solved this problem with a pattern that we will call Store and Forward (SaF).
Interestingly, such high-level patterns are not necessarily best illustrated using UML class
diagrams (like the GoF design patterns). In fact, in this case, the essence of the SaF pattern is
much better captured by an activity sequence diagram.
Chapter 3
Before we ramp up, there is an interesting side note about the SaF pattern worth mentioning. Even
though the SaF pattern lives on a higher conceptual plane than the GoF design patterns, we will need a
lowly "bread and butter" design pattern to give it life. Specifically, the Singleton pattern will play a big
part in making SaF work.
In summary, we'll see the following patterns in application in this chapter:
❑ Decorator
❑ Façade
❑ Strategy
❑ Store and Forward (SaF)
❑ Singleton
First, we'll look at our business requirements. Then we'll do our analysis, and at that point we'll try to
identify the patterns that will best suit our needs. In doing so, we'll examine a few options before finally
settling on the approach we've outlined above.
Handling Orders
Before we delve into the detailed analysis and design phase, let's set up our business requirements and
"set the scene" for the application and its related technologies. That should help us get a feel for where
our application needs to go and how we will get it there.
Business Requirements
Our client is the company called Northwind Traders (that perennial favorite of all Microsoft
developers). Currently, Northwind's sales representatives take customer orders over the phone. Sam
Spade, Northwind's controller, just finished an order handling benchmarking study and fears that the
company's cost per transaction is too high. He has also read about how other companies have lowered
their business-to-business (B2B) transaction costs via Internet-based technologies. He thinks that maybe
Northwind could, too. With this idea (lowering order transaction costs via the Internet) in mind, Sam
starts meeting with the company's Technology Manager, Sally Server, and the Inside Sales Coordinator,
Laura Callahan.
During the course of these meetings, it quickly became obvious why order transaction costs were high.
Laura informed everyone that while revenues were increasing, customers were placing a higher volume of
smaller orders. She said that as a consequence of this change in customers' behavior, Northwind would
probably be forced to hire two more sales representatives. And to make matters worse, sales representative
costs were increasing since they were now receiving continuous specialized product training.
Since it seemed unlikely that customers would change their ordering behavior, everyone agreed that
Northwind needed a way to reduce the labor costs associated with placing orders. At this point, Sam asked
Sally whether or not some Internet-based B2B solution might automate the process. She thought this was a
good idea, but needed a little more information about how the sales representatives processed orders.
118
Laura explained that the ordering process was simple, but setting up new customers and answering
product questions was complicated! Most existing customers already knew the product line and simply
called in their orders to a representative, who then reviewed the order and entered it into Northwind's
Order system. This review involved verifying product identification numbers and prices, checking
product stock levels, and stopping orders with past delivery dates.
Based on all this information, Sally believed that Sam's initial hunch was a good one. Order processing
costs could be lowered if the current manual order processing system was replaced with an Internet-based
application. The new application could receive customer orders over the Internet, review them, and enter
them into the order system. Laura was also enthusiastic; such a system would enable her staff to focus on
activities that improve sales, rather than wasting time pushing paper into a computer!
As a result, of these meetings, Jack Spratt was hired by Northwind to design and build an order
processing application.
Technology Requirements
In this chapter, we'll consider Northwind as a "Microsoft shop". All computer hardware runs on either
Windows 2000 Server or Windows 2000 Professional/Windows XP. All business applications are
written in Visual Basic. The corporate database is SQL Server 2000.
Sally stated that the new system must utilize these existing technologies. The only exception to the rule
would be the development language. She specified C# as the target language for the new application
(citing Northwind's recent decision to move onto the .NET platform).
While Jack had not yet started the analysis and design phase for the application, he was nonetheless
forming a few ideas about what technologies he might employ for the application. For example, some
combination of MSMQ queuing services and multithreading promised a reliable and responsible order
processing application capable of meeting the needs of web-based clients. Also, .NET's COM Interop
capability might ease communication with the legacy Microsoft-based order system.
Analysis and Design

After several days of discussion with the sales representative, the time came for Jack to document his
observations and ideas. He decided to use the Unified Modeling Language (UML) for the job, because
of its effectiveness at expressing so many different concepts with its tools. The exercise would also help
verify his ideas with the domain expert, Laura, and wrap up any outstanding security and deployment
issues with Sally.
If you're unfamiliar with the UML and its notation, you may find the UML Primer (located in
Appendix A) to be a helpful resource. The primer is also a great refresher for anyone who has not
worked with the UML for a while.
119
Chapter 3
Use Case Diagrams

Jack started by writing the use cases to describe the movement of orders from an ASP.NET page to
Northwind's Order system. The resulting use case diagrams provided documentation of many of the
application requirements. During the interviews, a name for the new application crystallized –
Northwind Order Processing (NOP). The first artifact produced for Laura's review was a preliminary
draft of the Primary Use Case. This preliminary draft is shown here:
NOP
Order Processing
Inventory
uses
Customer uses
Status Validate User
Order
In the simplest terms, NOP identifies a Customer actor and allows that actor to perform one of two actions:
❑ Submit an order. The Order Processing use case handles this action.
❑ Retrieve order status. The Status use case handles this action.
The third use case in this diagram, Validate User, does exactly what the name implies: it checks a user's
right to perform a particular activity. The remaining actors, Inventory and Order, represent other
Northwind systems external to NOP.
If you're new to UML, you might be surprised to see a computer application referred to as an
"actor" in a use case diagram. Nonetheless, those cute little stick figures can represent almost
anything that interacts with the main use case – human or non-human.
Laura believed that this preliminary version of the primary use case captured the spirit of the
application. She subsequently provided the details needed to construct the business rules for the Order
Processing use case. (Later, we'll see some activity diagrams that relate much of this information.)
Discussion with Sally cleared up a few key issues suggested by the preliminary Primary Use Case draft:
❑ The web page responsible for accepting customer orders would handle user authentication
and authorization. Her team was already building an ASP.NET application utilizing its latest
security widgets. Therefore, NOP did not need to validate users.
❑ The Inventory actor amounted to a legacy application built with Visual Basic 6. (Jack laughed
to himself at hearing a VB6 application described as a "legacy" system.) This system managed
Northwind's product price and quantity data.
❑ The Order actor provided the big surprise. This actor equaled Northwind's recently-built
Order system that incorporated XML and MSMQ. In this system, orders are initiated by
dropping an XML-based order document into a specific message queue.
120
Jack added this newly acquired information to the diagram, and thus finalized the Primary Use Case:
NOP
Order Processing VB 6 DLL

Inventory
Customer
Status XML to MSMQ

WebService via OrderInfo.aspx
Order
Activity Diagrams
Laura reviewed the activity diagrams that describe the processing that each order is submitted to before it
is passed to Northwind's Order system. The preliminary and final diagrams did not vary too much – Jack
had captured the business rules quite well! But, once again, the analysis produced a surprise. It turned out
that the Order system handles two different types of order documents – and they use different XML
document validation specifications! One type (the "Special Order") worked with an older XML validation
standard – DTD documents. The other ("Order") adhered to the latest standard from the W3C – XSD.
There was some similarity in the processes required for the two different types of order: both required a
check against the inventory and both resulted in the placement of an order into Northwind's Order
system. However, differing business rules complicated things. "Special Order" did not check order
credit limits or deal with required ship dates. "Order" did check credit limits and ship dates. These
different business rules, combined with the different XML document validation specifications, made the
order process confusing!
Jack summarized these differences with a simple table. The first column contains a brief description of
the processing action. The second and third columns contain how that action might be effected in NOP.
He saw three choices: Not Required, XML Validation, or Code:
Order Processing Action Effect of Action on Order Processing
Special Order Order
Inspect Product ID Code XML Validation

Inspect Price Code Code
Inspect Quantity Code XML Validation
Inspect Date Not Required Code
Check Inventory Code Code
Check Credit Not Required Code
Order Product Code Code
121
Chapter 3
Based on this table, Jack produced the following Order Processing and Validate activity diagrams:
Order Processing Validate Special Order Validate Order
Validate Special Order Validate Order Inspect Product ID
Check Inventory Check Inventory Inspect Price Inspect Price
Check Credit Inspect Quantity
Order Product Order Product Inspect Date
In the Validate Order activity diagram, note that Order does not explicitly need to inspect the
ProductID and Quantity, because this is done in the XSD schema.
It was at this point that Jack started thinking in terms of design patterns. Two ideas came to mind. First,
the Validate Special Order and Validate Order activities hinted that the Strategy pattern might be
appropriate when coding the validation process. Second, the similarities of the two order types (outlined
above in the Order Processing activity diagram) far outweighed their differences. One only needed to drop
a few behaviors from one to realize the other. This characteristic suggested a Decorator pattern to Jack.
Homing in on Patterns
Of course, it would be naive to assume that Jack selected these two patterns without some serious
thought. In fact, he worked though several possibilities before making these selections. Let's examine
Jack's decision-making process in greater detail.
Application of a Decorator pattern wasn't immediately obvious. But Jack looked at the different action
states of the Order Processing activity diagram, and realized that he could think of them as responsibilities
that could dynamically be added to (or dropped from) any order. Then he looked again at the
Decorator pattern's intent:
❑ Intent of GoF Decorator: Attach additional responsibilities to an object dynamically.

Decorators provide a flexible alternative to subclassing for extending functionality.
This was enough to convince him that a Decorator pattern could do the job.
122
If the activity states had been richer, more complex objects, then the Decorator would have looked less
appealing (because the Decorator assumes a certain "likeness" between the supporting objects, which
simply "decorate" the common object). In that case another structural pattern, the Composite, would
have been more promising. The Composite pattern's intent shows the difference:
❑ Intent of GoF Composite: Compose objects into tree structures to represent part-whole hierarchies.
Composite lets clients treat individual objects and compositions of objects uniformly.
(Chapter 1 contains descriptions and demonstrations of both of these patterns. If the Decorator pattern
seems a little hazy, you could turn back to Chapter 1 and reacquaint yourself with it. The Decorator
plays a central role in our application!)
Finding the most suitable pattern for Validate Special Order and Validate Order activity states proved a
more daunting task. The reason was simple: at first it was unclear to Jack what type of pattern best
suited the problem! He took a few minutes to examine the three different GoF design pattern types in
turn, remind himself of the high-level purpose of each, and eliminate some pattern types from the hunt:
❑ Creational patterns abstract object instantiation. While this functionality might be required to
implement validation, flexible object creation was not really an issue here. (Scratch
creational patterns.)
❑ Structural patterns help build large, complex objects. Validation objects did not look like they
would end up as multi-faceted behemoths. (Scratch structural patterns.)
Behavioral patterns play with algorithms and relationships between objects. Judging from the
Validate Special Order and Validate Order activity diagrams, managing algorithms seemed to
hit the mark best.
By deciding upon a behavioral pattern, Jack reduced the problem to picking the best pattern from a
smaller pot. Judging from its intent, the Command had some initial appeal:
❑ Intent of GoF Command: Encapsulate a request as an object, thereby letting you parameterize
clients with different requests, queue or log requests, and support undoable operations.
But this looked like overkill. Well, what about the Strategy and Template Method patterns? Both intents
looked promising:
❑ Intent of GoF Template Method: Define the skeleton of an algorithm in an operation,

deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of
an algorithm without changing the algorithm's structure.
❑ Intent of GoF Strategy: Define a family of algorithms, encapsulate each one, and make them
interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Jack pondered this one for a while, and even looked at some code samples to help get a better take. It
was looking at the code that helped him differentiate between these seemingly similar patterns. The
Template Method pattern enforced the same algorithms. The validation algorithms suggested in the
Order and Validate Order activity diagrams were not so common as to merit a straitjacket approach. Jack
felt that the Strategy pattern captured the requirements of the validation activity states much more
successfully – they looked like a "family" that needed to be "interchangeable" when it called for it.
123
Chapter 3
Sequence Diagrams
Early on, Jack decided that he would deal with business rules and performance requirements as two
different issues. To avoid mixing "plumbing code" with "business code", he decided to split NOP into
two applications, ReceiveDocument and ProcessDocument. ReceiveDocument would focus on
responding reliably and quickly to web clients; ProcessDocument could process order documents. But
the decision to split up NOP begs the obvious question – how will all these parts work together?
The UML's sequence diagrams love to answer questions like this. However, they do more than just map
out the dynamic exchange of messages between objects. Sequence diagrams also give the architect a
sense of the chronological ordering of messages. In our case, that's more than a trivial concern, since
NOP must support a B2B web-based client. Order processing will most likely be a time-consuming
exercise, and clients will not want to wait around for it to finish computing before they get a response!
Our sequence diagram will need to demonstrate how the ReceiveDocument application will get its job
done while keeping client responses timely. Oh, and don't forget, we'd better not lose any orders either.
Fortunately, Jack already knew how to handle this problem.
The solution amounts to a two-step process:
❑ First, safely store the end user's request and as quickly as possible return an informative response.
❑ Next, forward the request for processing, and when finished, allow the end user to retrieve the result.
Strangely, the pattern is so familiar to developers that build B2B Internet solutions that it doesn't even have a
name! Therefore, for the sake of simplicity we will refer to it as the Store and Forward (SaF) pattern.
No doubt, some readers are probably wondering why the Store and Forward pattern is considered a
"true" pattern. After all, there isn't a bunch of classes around to demonstrate it. However, a pattern
is more than just a class diagram; it is a time-tested solution intended to solve a recurring problem.
The Store and Forward pattern meets this criterion; it just turns out that a sequence diagram
communicates SaF's intent better than a class diagram.
As we can see in the following sequence diagram, the ReceiveDocument application embodies the SaF
pattern. It is responsible for storing the order (Send Message) and forwarding it to ProcessDocument
(Load). The last function it performs (Document ID) will allow the end user to get a Document ID, so
they can trace the order in the system.
:Receive :Pickup
Persist
Send Message
Execute
Document ID Load
ReceiveDocument
124
The second sequence diagram shows the whole process, and how ReceiveDocument fits into the
bigger picture:
:Client (Test Harness) :ReceiveDocument :ProcessDocument :LegacyWrapper :OrderManagement
XML String Persist XML
PickupAndProcess
Document ID Check Inventory
Place Order
X
X
Note that in the first sequence diagram, the Load message was drawn as a solid line with a one-sided
arrowhead. This notation represents a subtlety of the SaF pattern that is crucial if the pattern is to work
properly – namely, that the Load method will be an asynchronous method call without a return value.
Class Diagrams
With some solid use case, activity, and sequence analysis in hand, Jack was ready to design the class
structure. It also helped that he had envisioned the appropriate design patterns! Based on all analysis he
knew that ProcessDocument was the only application involving a complex web of classes. Therefore,
that was where Jack focused his class design energies.
Some readers may consider this miserly approach to class diagrams to be rather cavalier. We could
certainly diagram every class in NOP. However, would all these additional artifacts make us any
smarter? Probably not. So why bother generating many near-worthless diagrams?
The Decorator Pattern Classes

To implement the Decorator pattern, Jack needed to identify the concrete class and all of the associated
decorator classes. In our case, Jack already knew that the concrete class equated to an order document.
Therefore, he aptly entitled this class Document. The decorators equated to the different activity states
from the Order Processing activity diagram. He named each of these classes with a simplistic verb-noun
combination indicative of their function. For example, the CheckInventory class decorates a
document by checking (the verb) inventory (the noun).
Next, Jack decided what methods the concrete Document class should contain. This constituted a critical
design task since these methods would be available to every class in the pattern! He knew to avoid the error
of including any optional or specialized methods, since they rightly belonged to decorators. He rightly
kept the list focused on those methods most likely required by all order documents:
125
Chapter 3
Method/Property Description
Load() Loads the order document into a private XML document variable via the
private function LoadXMLDoc
DocID Returns the document's assigned processing reference ID (not to be
confused with an Order ID!)
DocXML Returns a reference to the private XML document
DocType Returns the document type (Special Order or Order)
DocStatus Returns the current status of the document ("processing", "errors",
or "complete")
DocErrors Returns a listing of any errors encountered while processing a document
With the above list of methods, the task of writing the Decorator's interface class (the
ProcessDocument class) was an academic exercise. Likewise, writing the Decorator pattern's decorator
class (the Processes class) proved an equally easy task since it just implemented all of the Document's
public methods.
The Strategy Pattern Classes

Compared to creating the Decorator, designing the validation processes via the Strategy pattern was
straightforward. Jack jumped straight to writing the interface class, OrderValidationStrategy. He
knew exactly the methods and properties he wanted any order validation class to offer:
Method/Property Description
IsValid() Returns a Boolean value indicating whether or not the document is valid
ValidationErrors() Returns a listing of any errors encountered while validating an order
The Strategy pattern had effectively transferred the "hard work" to the coding of the validation
algorithms. And that did not surprise Jack, given the Strategy pattern's intent – Define a family of
algorithms, encapsulate each one, and make them interchangeable…
126
The Final Class Diagram

Here's how the Decorator and Strategy patterns combine to produce the final class diagram for the
ProcessDocument application:
interface
ProcessDocument
OrderManager +Load()
+Load() +DocID()
-SetStatus +DocXML()
+DocType()
+DocStatus()
+DocErrors()
Document Processes
+Load() +Load()
+DocXML() +DocXML()
+DocType() +DocType()
+DocStatus() +DocStatus()
+DocErrors() +DocErrors()
-LoadXMLDoc() +New()
+XMLValidationEventHandler()
ValidateDocument CheckInventory CheckCredit OrderProduct

+New() +New() +New() +New()
+GetOrderID()
Decorator Pattern
interface
OrderValidationStrategy
+IsValid()
+ValidationErrors()
ValidateSpecialOrder ValidateOrder
+IsValid() +IsValid()
+ValidationErrors() +ValidationErrors() Strategy Pattern
+New() +New()
Jack has done enough plotting and planning. Let's move on to the code!
127
Chapter 3
The Coding Part

Our demonstration will be built as a collection of projects sitting within the Visual Studio .NET solution
entitled Wrox.ProDPA6985.Ch03. To create the application, there are four major tasks:
❑ Set up the infrastructure (for example, create the database storing document status messages).
❑ Build the debugging and test harness (TestHarness) application.
❑ Build the projects for the supporting applications (LegacyWrapper and OrderManagement).
❑ Build the two NOP applications (ReceiveDocument and ProcessDocument).
As a side note, you may have noticed that the test harness application is listed before the NOP
application. This is deliberate. Writing the test harness first helps ensure that we don't "lose sight" of our
goal when we actually get coding.
This methodology may sound familiar to you. It constitutes a significant part of the "Extreme
Programming" practice. One of its tenets holds that developers always build their application test
harness first. This forces the developer to be sure of exactly what features the application needs to
support, and also facilitates unit testing during the coding phase. There's a lot more to Extreme
Programming than this particular tenet. If you wish to learn more about Extreme Programming,
Kent Beck's book Extreme Programming Explained: Embrace Change (Addison-Wesley, ISBN: 0-
201616-41-6) is a good place to start.
There are a few miscellaneous points worth noting before we start coding:
❑ While NOP will someday support a web service, we're building a fat client for debugging and
testing. Bringing web services into the picture during the construction phase only adds an
unnecessary layer of complication.
❑ Just because we test with a fat client does not mean we can ignore the requirements of a web
service. For example, one of those requirements concerns acceptable parameter data types.
The current specification does not allow for passing an XML document as a parameter.
Therefore, we used a string value representation of an XML document.
❑ We're not worrying about where our XML validation files are physically located since all of
our applications run under one solution. Once loaded into memory by the test client, they
remain loaded. In reality, NOP would need to look in its own cache for the necessary DTD
and XSD validation documents.
Setting up the Infrastructure

Before coding, we need to do a little infrastructure-related work:
1. Register the "legacy" component Inventory.dll.
2. Verify (and, if required, install) the Windows MSMQ service.
128
3. Ensure that our two SQL Server 2000 databases are available.
4. Create a Visual Studio .NET solution.
In this section, we'll cover these four tasks.
Registering Inventory.dll
In spite of all of the new toys and widgets contained in Visual Studio .NET, you still need to make sure
that your computer's registry knows about any COM components it might utilize. In this demonstration,
the NOP application will make use of the Inventory.dll component library.
Save the file Inventory.dll to a folder on your hard disk, then navigate a command prompt to that
folder and execute the following command:
regsrv32 Inventory.dll
This will register the component library, and allow us to access it via COM Interop technologies.
We will examine the source code of Inventory.dll later in this chapter. The source code and
DLL are supplied along with the rest of the code for this book, at http://www.wrox.com.
Setting up MSMQ
Microsoft Message Queue (MSMQ) provides the private message queue services that NOP relies on to
persist order documents. It is a Windows 2000 component that may need to be installed locally. You
can check to see whether MSMQ services are installed on your machine, by activating the
Computer Management MMC via the Administrative Tools menu. The figure below indicates that
MSMQ is installed:
If your computer does not have Message Queuing listed under the Services and Applications node,
then install MSMQ via the Control Panel's Add/Remove Windows Components feature.
Setting up the SQL Server Databases

SQL Server 2000 humors two masters in our solution. First, it provides a single table data store for NOP's
document processing status messages. Second, it contains product data for the Northwind Inventory system.
129
Chapter 3
The Northwind Database

The legacy component library Inventory.dll (which was coded using VB6) retrieves product
information from the demonstration Northwind database that comes with SQL Server. You will need to
check that this database exists. After that, you will need to modify the connection information located in
the data link file. This file is called Nwind.udl – you can place it in the same folder as the
Inventory.dll file. You may want or need to update the password. The following shows what you
can expect to find on the Connection tab of the Data Link Properties dialog:
The NWindOrderStatus Database

The other SQL Server database, NWindOrderStatus, supports status processing message persistence.
You can create it by using the Create-NWindOrderStatus-Database.sql script, which is located
in this chapter's \SQLScript folder. Before executing this script, you may need to edit the database and
log file locations. In particular, if your computer does not have the
C:\Program Files\Microsoft SQL Server\MSSQL\data folder (which is assumed in the following lines of
the .sql script), you'll need to edit the script and set another folder:
IF EXISTS (SELECT name FROM master.dbo.sysdatabases

WHERE name = N'NWindOrderStatus')
DROP DATABASE [NWindOrderStatus]
GO
CREATE DATABASE [NWindOrderStatus]

ON (
NAME = N'NWindOrderStatus_Data',
FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL\data\NWindOrderStatus_Data.MDF',
130
SIZE = 1, FILEGROWTH = 10%)

LOG
ON (
NAME = N'NWindOrderStatus_Log',
FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL\data\NWindOrderStatus_Log.LDF',
SIZE = 1, FILEGROWTH = 10%)
...
Note that the T-SQL CREATE DATABASE command will fail if the FILENAME folders do
not exist!
Create-NWindOrderStatus-Database.sql also creates a few other SQL Server objects that our
document processing application relies upon. The most important of these, of course, is the
DocumentStatus table – this is the home of the status records. The other object is a SQL Server-based user
identity called DocWrox, which has the necessary permissions to access the NWindOrderStatus database.
If your instance of SQL Server 2000 only supports Windows authentication, then you will need to
change this option to support SQL Server authentication too. This may be accomplished through the
SQL Server Enterprise Manager MMC – select the SQL Server instance's Properties page and
from there select the Security tab. After changing the Authentication property, SQL Server will
need to be restarted.
Creating a Visual Studio .NET Solution

In the following section, we will start building the first of several C# projects. To keep the development
effort more manageable, you may at this time want to create a blank solution entitled
Wrox_ProDPA8740_Ch03 that will house all of our handiwork (It's also the way I wrote the source
code for this project). When we are finished coding, our Solution Explorer window should contain five
projects as shown below:
The Inventory
Before delving into Northwind Order Processing (NOP), it's worth taking a moment to inspect the
applications that provide product data via Northwind's Inventory application. Accessing this "legacy"
application is accomplished via a simple .NET application entitled LegacyWrapper.
For once we have a really meaningful (albeit boring) application name – LegacyWrapper! OK,
maybe this name is only meaningful to hardcore object-oriented developers. These guys regularly apply
the term "wrapper" when they use either the Adapter or Façade patterns to protect the innocent from a
legacy application. In our case, our application is using a Façade to "wrap" a dangerous and scary
VB6 component! To highlight an extra source of ambiguity, we should note here that the GoF also
listed the term "wrapper" as an alternative name for a Decorator design pattern.
131
Chapter 3
The Façade pattern provides us with more than just an exciting lesson in nomenclature. First, it (almost)
spares us from having to read the next few paragraphs since it shields us from the inner workings of
Inventory.dll. Second, it helps keep our architecture simpler. We can get a visual idea of this notion
by augmenting a fragment of the ProcessDocument class diagram with the LegacyWrapper
application's ProductInventory class diagram, as shown overleaf:
Processes
+Load()
+DocXML()
+DocType()
+DocStatus()
Decorator Pattern +DocErrors()
(Partial) +New()
CheckInventory
+New() ProcessDocument
Application
LegacyWrapper
Application
Façade Pattern ProductInventory
+CheckProductPrice()
+UnitsInStock()
The Legacy Application

We now need to find a few things out about our legacy VB6 application, Inventory.dll – and in
particular, its single class file, Product.cls. If you have Microsoft Visual Basic 6 installed, then it will
help to make the code review more palatable; if not, you can also use Notepad to view the code. When
looking at the code, pay special attention to any issues that might arise when writing a .NET-based
wrapper around Inventory.dll. For example:
❑ Are there any data type conversion issues? Remember that the .NET Common Language
Runtime (CLR) does not work easily with all Visual Basic 6 data types.
❑ Is the Visual Basic class public? In other words, is the class instancing property set to
MultiUse rather than Private?
Let's step through the code in Product.cls, and pick out the key elements. The first thing we notice is
that the class instancing property is set to MultiUse:
VERSION 1.0 CLASS

BEGIN
MultiUse = -1 'True
Persistable = 0 'NotPersistable
132
DataBindingBehavior = 0 'vbNone
DataSourceBehavior = 0 'vbNone
MTSTransactionMode = 0 'NotAnMTSObject
END
Attribute VB_Name = "Product"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = True
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = True
Option Explicit
Great! This makes the VB6 Product class appear as a normal .NET public class.
There's more good news in the next fragment! Our first function, InstockCount(), has a plain old
integer data type that .NET happily works with. Also, ProductID is passed by value and that
minimizes the number of calls between COM and .NET:
Public Function InstockCount(ByVal ProductID As Integer) As Integer

On Error GoTo LocalError
Dim intResult As Integer
Dim strQuery As String
Dim cn As ADODB.Connection
Dim rs As ADODB.Recordset
strQuery = "SELECT UnitsInStock FROM Products WHERE ProductID = " & _

ProductID
Set cn = New ADODB.Connection
cn.Open GetConnectionString
Set rs = cn.Execute(strQuery)
If Not (rs.BOF Or rs.EOF) Then
intResult = rs(0)
Else
intResult = -1
End If
rs.Close
cn.Close
GoTo ExitFunction
LocalError:
Err.Raise Err.Number, "InstockCount", Err.Description
ExitFunction:
InstockCount = intResult
CleanUp:
If Not rs Is Nothing Then
Set rs = Nothing
End If
If Not cn Is Nothing Then
Set cn = Nothing
End If
End Function
133
Chapter 3
The data type of the return value is as important as the function's parameter type, and it is looking good.
The next function, PriceCheck(), appears as clean as InstockCount, because Doubles are as
digestible as Integers:
Public Function PriceCheck(ByVal ProductID As Long, _

ByVal Price As Double) As Integer
On Error GoTo LocalError

Dim intResult As Integer
Dim cn As ADODB.Connection
Dim rs As ADODB.Recordset
Dim strQuery As String
strQuery = "SELECT * FROM Products WHERE "

strQuery = strQuery & "ProductID = " & ProductID
strQuery = strQuery & " AND "
strQuery = strQuery & "UnitPrice = " & Price


Set rs = cn.Execute(strQuery)
If Not (rs.BOF Or rs.EOF) Then
intResult = 1
Else
intResult = -1
End If
rs.Close
cn.Close
GoTo ExitFunction
LocalError:
Err.Raise Err.Number, "PriceCheck", Err.Description
ExitFunction:
PriceCheck = intResult
CleanUp:
If Not rs Is Nothing Then
Set rs = Nothing
End If
If Not cn Is Nothing Then
Set cn = Nothing
End If
End Function
The VB6 code does not suggest any potentially vexing COM Interop issues. In particular, all method
parameters are passed ByVal and the parameters' and return values' data types are all "blittable". (In
other words, there are no special data conversion requirements between COM and .NET here. In some
cases, these requirements do exist. The cost can range from slight performance degradation to having to
tweak the code in places.) In addition, there are no complex data types – like VB6 user-defined types
(UDTs) or variant arrays (ugh!) – to deal with.
134
The code does contain one potential problem. Namely, the Inventory application requires the non-
.NET version of the ADO libraries. (This problem is so obvious that an experienced developer could
easily miss it.) Fortunately, that probably will not be an issue since the .NET runtime installs the latest
non-.NET version of ADO. Moreover, Product.cls does not appear to be making any "discontinued"
or deprecated ADO method calls.
Many readers of this book will be developers with several ADO libraries installed on their machine,
and to those readers this issue may seem academic. However, be warned! You never know what can
happen when deploying applications to "normal" desktops!
For those curious souls, GetConnectionString() refers to a function in a BAS module (Main.bas)
that loads the required connection information contained in NWind.udl:
Public Function GetConnectionString() As String

GetConnectionString = "file name=" & App.Path & "\NWind.udl"
End Function
Finally, if you have Microsoft's Visual Basic 6 installed on your computer, you can test the Inventory
application using the project contained in the \Legacy\Test folder.
The LegacyWrapper
Building a .NET application that communicates with Inventory.dll is a straightforward exercise.
After creating a new C# class library project, called LegacyWrapper, within our VS.NET solution, we
just reference the COM component and write a class that accesses it.
Pattern alert! We're creating a reference to another class with the sole intention of
merely calling its methods. This is the first step towards implementation of a Façade
pattern, as we'll see in this section.
Here's the Add Reference dialog that is presented by Visual Studio .NET when you add a COM
reference to the project:
135
Chapter 3
If you do not see Inventory.dll in the list of available components (as shown above), then try
registering the component using regsvr32 (as discussed earlier).
Now change the name of the class file created by VS.NET from Class1.cs to
ProductInventory.cs. We're ready to code our class called ProductInventory.
using System;
using Inventory;
namespace LegacyWrapper {
The ProductInventory class will be responsible for accessing the Inventory's Product class, and is
given below. Recall from our object diagrams that this class has two methods, CheckProductPrice()
and UnitsInStock():
public class ProductInventory {
ProductClass m_Inventory = new ProductClass();
public bool CheckProductPrice(int productId, double price) {
int result = 0;
try {
result = m_Inventory.PriceCheck(productId, price);
}
catch {
string msg = "Unable to check price for Product Id = " + productId;
throw new Exception(msg);
}
136
if( result > 0 )

return true;
else return false;
}
In the code above, our reinterpretation of m_Inventory.PriceCheck() now begins to look a

little bit like an Adapter pattern! We are definitely entering the territory of a Façade pattern; but
whenever code makes incompatible classes hospitable to another class the object-oriented purists might
yell, "Adapter!" (Whether or not the Product.cls code is inhospitable is for the reader to decide.)
public int UnitsInStock(short productId) {
int result = 0;
try {
result = m_Inventory.InstockCount(productId);
}
catch {
string msg = "Unable to retrieve units in stock " +"for Product Id = " +
productId;
}
return result;
}
}
}
Our interpretation of the information returned from the VB6 application makes it much easier to use
Inventory.dll. For example, look at the CheckProductPrice() method. It ultimately calls
Inventory.Product's PriceCheck() method, which returns an Integer. But the
CheckProductPrice() method returns a Boolean. That's because clients of the
CheckProductPrice() method just need to know whether the submitted product price was correct.
They don't care to know about a bunch of integers.
How the Façade Pattern is Helping Us

This situation is a good example of when a Façade comes to the fore. If the Façade pattern is well
implemented here, the LegacyWrapper developer will be the only person who ever needs to interpret
PriceCheck()'s return value. Other developers needing the functionality of the legacy
PriceCheck() method can bypass learning the intricacies of the Inventory application by just
calling CheckProductPrice(). In this simple example, the overall benefit is rather small. However,
it's clear that in a similar situation that involved dozens of complex methods, the benefit of the Façade
pattern would be multiplied manyfold.
Moreover, there is another way in which the Façade patterns may have simplified working with
Inventory.dll. Imagine that Product.cls contained 40 methods, instead of only two, and that the
other 38 of those methods were of no interest to us. We would probably prefer to hide these
nonessential routines from ProcessDocument. Thus, once again, the Façade helps us by being selective –
in other words, by excluding Inventory.dll's superfluous methods.
137
Chapter 3
The Test Harness

The NOP test client is a Visual Studio .NET Windows Application named TestHarness. We use it to
load and submit test versions of the two Northwind order types. More specifically, it places the contents
of either an Order or Special Order sample XML document into a textbox control. It also retrieves
processing status information after submitting an order. The user interface supports these simple
requirements. This is what it should look like:
Once you've added the TestHarness project to the VS.NET solution, change the name of the file
Form1.cs to frmMain.cs. Next, bring up the Properties pane (by hitting F4 and clicking on the form)
and change the Text property of the form frmMain from Form1 to Order Text Processing.
Now we can set about building the workings of the test application. First, we'll use the IDE features to
add some controls, and then we'll visit the code and add some further implementation.
Adding the Controls

Then we need to use the toolbox to add the necessary controls to the form. The controls are listed
below. The table also shows the properties whose values should be changed from the default (use the
control's Properties pane to set the values of these properties):
Control Property Name Property Value
Label Text XML

Label Text Document ID:
Label Text Order Status
Label Text Submit Order
Name lblSubmitResult
138
Control Property Name Property Vaule
TextBox Name txtXML

Multiline True
ScrollBars Vertical
TextBox Name txtCheckResult

Multiline True
ReadOnly True
ScrollBars Vertical
Button Text Submit Order

Name cmdSubmit
Button Text Check Order Status

Name cmdStatus
GroupBox Text Type

RadioButton Text Order
Name rbOrder
RadioButton Text Special Order

Name rbSpecialOrder
Just in case you're wondering why txtCheckResult is a read-only textbox, our intention is that it
should resemble a label. The explanation is simple. After submitting an order document, any error
message we receive will be displayed here. These error messages are read-only. They may also be quite
lengthy – a characteristic that suggests a multi-line feature. Unfortunately a label control lacks a
multi-line feature, so we use a textbox control instead.
Adding the Code

Now open the View Code pane, so that we can start adding the necessary implementation code to the
application. Start by changing the name of the form class from Form1 to frmMain, and adding the
following using instructions and variable m_DocReceive:
using System.Xml;
//using ReceiveDocument;
public class frmMain : System.Windows.Forms.Form

private System.Windows.Forms.Label label3;
private System.Windows.Forms.TextBox txtCheckResult;
private System.Windows.Forms.Button cmdStatus;
private System.Windows.Forms.Label lblSubmitResult;
private System.Windows.Forms.Button cmdSubmit;
139
Chapter 3
private System.Windows.Forms.TextBox txtXML;

private System.Windows.Forms.GroupBox groupBox1;
private System.Windows.Forms.RadioButton rbOrder;
private System.Windows.Forms.RadioButton rbSpecialOrder;
private System.ComponentModel.Container components = null;
//private Receive m_DocReceive;
Note that the lines referring to the ReceiveDocument.Receive class have been commented
out. This is because we have not yet built the ReceiveDocument application, so we can't
reference it yet! By commenting these lines out, we'll be able to test our TestHarness's ability to
load and read XML order documents; and later, when we've built the ReceiveDocument
application, we'll return to the TestHarness code and complete its implementation by adding the
ReceiveDocument.Receive class references.
The Radio Button Change Handlers

After the Windows Form Designer generated code, place the following methods, which handle a
change in the radio buttons on the form:
private void rbSpecialOrder_CheckedChanged(object sender, System.EventArgs e) {

LoadXML();
}
private void rbOrder_CheckedChanged(object sender, System.EventArgs e) {

LoadXML();
}
The radio buttons are used to determine which of the two order documents will be loaded into the big
textbox, txtCheckResult. In a moment, we will add code to make sure that rbSpecialOrder is
selected by default, thereby loading SpecialOrder.xml when the application starts up.
The LoadXML() Method

The workhorse of our test harness, the LoadXML() method, picks up one of the two test versions of the
order XML documents and then places its string representation into txtXML:
private void LoadXML() {

XmlTextReader objXML = null;
txtXML.Text = "<?xml version='1.0'?>" + Environment.NewLine;
if( rbSpecialOrder.Checked ) {
txtXML.Text += "<!DOCTYPE SpecialOrder SYSTEM 'SpecialOrder.dtd'>" +
Environment.NewLine;
objXML = new XmlTextReader(Environment.CurrentDirectory +

"\\SpecialOrder.xml");
}
else {
objXML = new XmlTextReader(Environment.CurrentDirectory + "\\Order.xml");
140
while( objXML.Read() )
txtXML.Text += objXML.ReadOuterXml();
txtXML.Focus();
txtXML.Select(0, 0);
txtCheckResult.Text = string.Empty;
lblSubmitResult.Text = string.Empty;
}
The Button Click Handlers

The command buttons' click events initiate communications with NOP. The cmdSubmit_Click routine
pushes an order's string-formatted XML data to ReceiveDocument. The cmdStatus_Click routine
retrieves information about how the submitted order fares in ReceiveDocument:
private void cmdSubmit_Click(object sender, System.EventArgs e) {

lblSubmitResult.Text = string.Empty;
//lblSubmitResult.Text = m_DocReceive.Persist(txtXML.Text);
}
private void cmdStatus_Click(object sender, System.EventArgs e) {

//txtCheckResult.Text = m_DocReceive.GetStatus(lblSubmitResult.Text);
}
Again, we'll comment out the m_DocReceive method calls for now, since we still don't have a
reference to the underlying ReceiveDocument.Receive class. We'll return to the application
to reinstate these lines of code later.
The Initialization Routine (and an Implementation of Singleton)

Finally, inside the frmMain() method that hides inside the designer-generated code region, add the
following code before End Sub. This code sets the rbSpecialOrder radio button to be checked when
the application loads. It also loads txtXML with data for a "special order" and gets a reference to
ReceiveDocument:
public frmMain() {
InitializeComponent();
rbSpecialOrder.Checked = true;
cmdSubmit.Focus();
//m_DocReceive = ReceiveDocument.Receive.GetInstance();
}
Did this last line of code appear a little unusual? It should have, because we instantiated the
ReceiveDocument.Receive class in an unusual fashion. We avoided the more typical call to the
default constructor method with a custom method entitled GetInstance(). The explanation is quite
simple – ReceiveDocument.Receive implements the Singleton design pattern.
141
Chapter 3
As we described in Chapter 1, the Singleton pattern allows only one instance of the subject class to be
created. It accomplishes this by modifying its default constructor from Public to Private. In addition,
with that one alteration only another public method within the class can deliver an instance of the same
class. In our case, the static method GetInstance() holds the keys to the kingdom.
Note that only a class's static methods can be called when the class is not instantiated.
The XML Documents

The last step for making TestHarness operational is to place the two XML documents referenced in
the LoadXML() method (SpecialOrder.xml and Order.xml) and their associated validation
documents in the \TestHarness\Bin\Debug folder. We can retrieve the folder name using the method
Environment.CurrentDirectory(). If the validation documents, SpecialOrder.dtd or
Order.xsd, are not dropped into the \TestHarness\Bin\Debug folder too, any attempt to read their
associated XML documents will result in an ugly error.
If you are unfamiliar with XML programming, it may prove to be a bit frustrating at first. For
example, in our code above, despite including the required validation documents, the XML
documents were not fully validated on loading. As we will see later, that requires an entirely
different step!
Building and Running the TestHarness Application

There's just one last thing to do: in the TestHarness project's properties, ensure that the Startup
object is set to frmMain. Now, if you've followed all the steps, you should be almost ready to build the
TestHarness application.
Once you've built it, you should be able to use it to load either the "Order" or "SpecialOrder" XML
documents (as a string) into the txtXML textbox control by clicking one of the radio buttons. While
you're testing the application, you may notice that txtXML accepts user edits and changes. This feature
will eventually allow us to "break" the order for NOP testing and debugging purposes. (That's what this
application is for, right?)
The two sample test XML documents (Order.xml and SpecialOrder.xml) can be found in
the \TestHarness\bin\Debug folder. If you move them elsewhere, don't forget to grab their
soulmates (Order.xsd and SpecialOrder.dtd), too!
A Note about the ReceiveDocument.Receive Class Method Calls

There's one last "gotcha" that you might want to keep in mind for when we've created
ReceiveDocument and we are ready to test. At that time, we not only need to reinstate the
commented-out code; we also need to add a reference to the ReceiveDocument application. You will
know if you forgot this last detail if the following message box pops up when running the debugger:
142
This is the kind of situation in which it's useful to use the VS.NET IDE's Task List feature. Bring up the
Task List pane (Ctrl+Alt+K) and right-click on it to change the filter to All. Now right-click on each of
the four commented-out lines that refer to the ReceiveDocument.Receive class, and select
Add Task List Shortcut. This will add four tasks to your task list, like this:
You now have a nice reminder of what to fix patiently awaiting your attention!
The Middle Tier

We are now ready to build Northwind Order Processing (NOP). As soon as its first component,
ReceiveDocument, begins to take shape, we will be able to start putting our TestHarness to work! In
addition, when ReceiveDocument looks viable, we can then build the "business brains" of our
application – the ProcessDocument component.
The ReceiveDocument Application

NOP must thrive reliably in a fast-paced Internet environment, and as we've discussed, this suggests a
need for the Store and Forward (SaF) pattern. ReceiveDocument constitutes the solution to this
problem. In effect it is the "plumbing" code for NOP. While ReceiveDocument will ultimately send all
order documents to ProcessDocument, it accomplishes two goals before that handover:
❑ First, order documents are temporarily placed into a local queue. As soon as that is
accomplished, it returns document identification to the client. Since this process occurs
promptly, the end user experiences a minimal response time to their HTTP-based request.
❑ Second, almost as quickly as the client gets their response, document processing is initiated.
During the processing the client can request status messages for this recently submitted order.
And when document processing is completed, the client can receive the "official" order
identification via the same status messaging feature.
The application contains three significant classes: QueueManager, Receive, and Pickup. I suspect most
readers will guess what QueueManager does – it creates and provides a reference to a queue. The
functions of the other two classes may not be so obvious. Between them they manage the two parts of the
Store and Forward pattern: Receive manages the "store" part, and Pickup manages the "forward" part.
For those who like to read the end of the story first, here is a snapshot of how the ReceiveDocument
application's Solution Explorer should end up:
143
Chapter 3
The QueueManager Class

The QueueManager class provides us with one more bit of infrastructure (well, sort of), by performing a role
that is vital to the implementation of our Store and Forward pattern. Not only does it return a reference to the
queue in which inbound messages are temporarily persisted; if necessary, it also creates the queue.
After creating the ReceiveDocument project (a C# Class Library project) to the VS.NET solution,
remove the default class file (Class1.cs) and add a new class file called QueueManager.cs. To the
ReceiveDocument project you will need to add a reference to the Microsoft messaging component
(System.Messaging.dll) as shown below:
Finally before we start coding the class itself, we'll add the following using statements (which will help
us to keep the object references short):
using System.Messaging;
using System.Threading;
namespace ReceiveDocument {
144
OK, let's get started. The first thing to notice is that we change the class modifier from public to
internal, to keep the riff-raff from using the QueueManager. Of course, if we had left
QueueManager public our application would not crash if misused (hopefully). But experienced
object-oriented developers might get confused. They expect public classes to be available for
public consumption:
internal class QueueManager {

private const string QUEUE_NAME = "InboundDocuments";
The beauty of a centralized queue manager shows up immediately. While we called our queue
InboundDocuments, you could use any other name here without breaking anything.
The .NET Common Language Runtime (CLR) exposes a wide variety of thread-locking mechanisms.
We're not obliged to use a Mutex object here, but I find it provdes the right mix of flexiblity and effort
compared to the other .NET locking techniques:
private static Mutex m_Mutex = new Mutex();
It is interesting to note, though, that as we discuss patterns, details such as a language's thread locking
and synchronization methods are not too important.
The class has a single method, GetQueue(). Notice the m_Mutex.WaitOne() call here – we'll discuss
what the Mutex is doing in a moment:
public static MessageQueue GetQueue() {

MessageQueue msgQueue = null;
string msgQueueName = ".\\private$\\" + QUEUE_NAME;
m_Mutex.WaitOne();
If desired queue exists on our computer, we'll grab it. We'll use an If clause for this:
if( MessageQueue.Exists(msgQueueName) {
try {
msgQueue = new MessageQueue(msgQueueName);
}
catch( Exception ex ) {
string msg = "Unable to access the " + QUEUE_NAME + " queue";
throw new Exception(msg, ex);
}
finally {
m_Mutex.ReleaseMutex();
}
}
But if the queue does not exist, then we will create it.
145
Chapter 3
else {
try {
msgQueue = MessageQueue.Create(msgQueueName, true);
}
}
finally {
m_Mutex.ReleaseMutex();
}
}
return msgQueue;
}
}
}
Setting the second parameter of MessageQueue.Create() to true creates a transactional queue,

rather than the default non-transactional one. When the time comes to process order documents, this
queue property will help improve the application's reliability. The feature supports some cool
transactional things, such as committing or rolling back retrieved messages. For example, let's say we
picked up a message for processing and the process failed. We can automatically put the message back
in the queue with a simple abort command.
The use of the Mutex object precludes a significant problem that would otherwise come into play in a
multithreaded application such as ReceiveDocument. To understand this problem, consider what
would happen if two threads both reach the following line of code before the queue msgQueueName is
available or created:
if( MessageQueue.Exists(msgQueueName) )
Not surprisingly, in this scenario there would be two efforts to create the same message queue – and this
is a behavior that we want to avoid! By locking things up temporarily (via the m_Mutex.WaitOne()
method call), we prevent that problem. If you're worried about the performance hit associated with such
an approach, note that we avoid that issue by maintaining a reference to this queue in our
ReceiveDocument.Receive object. This avoids the need to make locking calls to check whether or
not the queue exists.
The Receive Class

The Receive class gets the ball rolling as far as the presentation tier is concerned. However, it operates
in a slightly unusual fashion. Clients cannot instantiate it directly, because Receive is designed as a
Singleton class. If you're new to design patterns then this paradigm may strike you as strange; however,
it provides the application with some significant advantages:
❑ First, clients will not most likely have to wait for an instantiation process with every call. Once
a singleton is instantiated, it becomes available to any and all callers. As we saw in Chapter 1,
it accomplishes this feat by disallowing arbitrary clients from instantiating it via the default
constructor. If a client requests a singleton object, they must acquire it by calling some
cleverly named public method like GetInstance(). That method will return a reference to
the instantiated singleton object.
146
This arrangement also absolves the caller from worries relating to instantiation issues. The
singleton itself figures out the complexities of instantiation, before returning a reference to it.
In other words, the Singleton pattern even abstracts away any creation woes from the caller.
And it does so with minimal cost – the caller only needs to know that magic method that we
called GetInstance() instead of the default New() constructor method.
❑ Second, access to and usage of the application's underlying resources can be optimized. In a
moment, we will see an excellent example of this feature as we work with a message queue object.
Let's build the Receive class. We'll create a new class file, Receive.cs, and start to add the following code:
using System.Data;
using System.Data.SqlClient;
public class Receive {

private const string CONNECT_STRING =
"server=Localhost;uid=DocWrox;database=NWindOrderStatus";
If your SQL Server instance is not hosted on your LocalHost machine, then you may need to
change the server attribute here to reflect that. The uid and database (DocWrox and
NWindOrderStatus) were created by the Create-NWindOrderStatus-Database.sql
script that we ran earlier (in the SQL Server setup section) – you shouldn't need to change those
attributes unless you also changed Create-NWindOrderStatus-Database.sql.
There are three more private member objects that we'll need:
private static Receive m_Instance = null;

private static MessageQueue m_MsgQueue = null;
//private Pickup m_Pickup = new Pickup();
There are a couple of points here. First, in creating m_MsgQueue, we begin the demonstration of how a
Singleton pattern helps resource management. We will ultimately set it to a queue once and only once –
when we instantiate the Receive object. This minimizes the negative performance impact that we incur
by using a Mutex in QueueManager.
Second, note that later on we will need the reference to the Pickup class, but we haven't built that class
yet – so for testing purposes we will comment out this line for now. (Again, you could add a task to your
Task List to remind yourself that we need to return to this!)
The GetInstance() method works in combination with the m_Instance shared variable to provide
instances of Receive:
public static Receive GetInstance() {

if( m_Instance == null ) {
m_Instance = new Receive();
m_MsgQueue = QueueManager.GetQueue();
}
return m_Instance;
}
147
Chapter 3
The class needs a constructor, but we will set it to Private. If we failed to restrict access to the default
constructor, we could bet someone will call it. That would nullify our efforts to create a more efficient
Receive class:
private Receive() {}
The Persist() method delegates most of its work to two other key methods. The first method,
SendMessage(), we will look at shortly. The other temporarily commented one, the Execute()
method of the Pickup class, will ultimately contribute significantly to the client's perception of
NOP's performance:
public string Persist(string xmlText) {

string docID = string.Empty;
try {
docID = SendMessage(xmlText);
}
string msg = "Unable to recieve document";
}
m_Pickup.Execute(docID);
return docID;
}
Note that in this method, docID is not just another return string. It provides a reference to the client for
checking the status of their submitted order documents. Since NOP doesn't complete processing before it
sends a response, there needs to be a mechanism that allows clients to get information about their
submitted orders. In our application, we use "status" messages to provide this service. The following
information flow diagram summarizes this process:
Presentation Tier
Submit Document
docID NOP
ReceiveDocument
Document
docID Status NWindOrderStatus
Messages
Document Status ReceiveDocument
148
We use a fairly simple but effective method to generate the docID.
The message queue assigns a unique value to each successfully received message (or, in our case,
successfully received document). We'll use this identification number for our docID. This identification
number possesses another nice feature, aside from uniqueness: embedded within it is a GUID reference
to the machine that houses the queue.
The value of a reference to a specific machine is really enhanced once NOP is placed on several web
servers. Then, if one of these servers breaks down, it's easy for an administrator to check the
document status log and see which items were left in limbo. (We could write another application to
help manage "lost" messages, but that can be covered in another book all together.)
We'll take a look at the private SendMessage() method in a moment, but first let's complete the list of
public methods by putting down the code for GetStatus(). The GetStatus() method responds to
end user requests for information about a specific, recently submitted order. It utilizes basic ADO.NET
tools and we will not spend too much time discussing them:
public string GetStatus(string docID) {

string result = string.Empty;
string sql = string.Empty;
SqlConnection cn = null;
SqlCommand cmd = null;
sql = "SELECT TOP 1 Status FROM DocumentStatus";

sql += " WHERE DocumentID='" + docID + "'";
sql += " ORDER BY StatusID DESC";
try {
cn = new SqlConnection(CONNECT_STRING);
cmd = new SqlCommand();
cmd.CommandType = CommandType.Text;
cmd.CommandText = sql;
cmd .Connection = cn;
cn.Open();
result = (string)cmd.ExecuteScalar();
if( result == null )

result = "Pending";
}
string msg = "Unable to retrieve status for DocID = " + docID.ToString();
}
finally {
if( cn.State != ConnectionState.Closed )
cn.Close();
}
return result;
}
149
Chapter 3
With the public methods out of the way, it's time to look at the heart of the Receive class – the
SendMessage() method. It is all about one thing – getting our recently received XML order data into
the InboundDocuments queue:
private string SendMessage(string xmlText) {

string docID = string.Empty;
Message msgDoc = new Message();
MessageQueueTransaction msqTrx = new MessageQueueTransaction();
Since we created the InboundDocuments queue as transactional, we need the supporting MSMQ
transaction object to send messages. Later on we will harvest the benefits of this additional work.
Transactional MSMQ queues are not all the same. In our case, the transaction attribute implies an
internal MSMQ-specific transaction. It is not the same type of transaction associated with
COM+ Services.
The first thing to do here is set the properties of the message:
msgDoc.Label = DateTime.UtcNow.ToString();
msgDoc.Formatter = new BinaryMessageFormatter();
msgDoc.Recoverable = true;
msgDoc.Body = xmlText;
Setting the message's recoverable property to True adds another layer of reliability to our application.
It forces MSMQ to persist the message to disk immediately, rather than keeping it temporarily cached
in memory until a good moment comes along to flush it to disk. While this feature potentially slows
MSMQ a little, it also prevents a crashed web server from losing any messages!
Now we can attempt to send the message:
try {
msqTrx.Begin();
m_MsgQueue.Send(msgDoc, msqTrx);
docID = msgDoc.Id;
msqTrx.Commit();
}
msqTrx.Abort();
string msg = "Unable to send message to the " +

m_MsgQueue.QueueName + " queue";
}
finally {
m_MsgQueue.Close();
}
return docID;
}
}
150
Testing the Receive Class

We can perform some serious testing via the TestHarness application. To do that, we must first make
a few simple modifications to it:
❑ First, remove the comment quotes on the four lines that alluded to ReceiveDocument
and Receive.
❑ Next, add a reference to the ReceiveDocument application:
❑ Finally, if you added those four tasks to your Task List, you can remove them now – they
have fulfilled their purpose!
After completing these tasks we are ready to rebuild the TestHarness application and use it to submit
a few test orders. After submitting some orders, check your Computer Management MMC. If
ReceiveDocument executed without any errors, your MMC should resemble the following screenshot.
In the sample below, two order messages sit patiently in the inbounddocuments queue:
151
Chapter 3
The Pickup Class

The application's last remaining class, Pickup, undertakes another simple responsibility – kicking off a
thread that ultimately processes the order currently ensconced in the InboundDocuments queue.
Nonetheless, it does so with a degree of panache that fulfills the "Forward" requirement of the Store and
Forward design pattern. The magic of threading and transactional queues makes it happen.
We can see where the Pickup class comes to the fore, by walking through ReceiveDocument's
sequence diagram:
:Receive :Pickup
1
Persist
2
Send Message
5 Execute 4
Document ID 3 Load
ReceiveDocument
1. Persist. Order document is received from the presentation tier (TestHarness).
2. Send Message. Order document is placed in the InboundDocuments queue.
At this stage, the "store" portion of SaF is completed. Pickup initiates the "forward" part:
3. Execute. Order document is prepared for handoff to the ProcessDocument application.

This involves wrapping it in a utility class (PickupAndProcess) that can be passed inside
of a thread.
4. Load. PickAndProcess object is sent to ProcessDocument (via a thread).
With Pickup's processing completed, we go back to Receive so it can send the client a response:
5. Document ID. After Step 4 has kicked off, the client is sent a reference to their submitted
Order document for future status queries.
OK, let's build the Pickup class now. Add a new class file, Pickup.cs, to the ReceiveDocument
project. Then, add the following using statements to the file:
//using ProcessDocument;
152
Once again, we're commenting out the last of these Import statements because we haven't built the
ProcessDocument application yet. We'll return to this code to instate this line once the
ProcessDocument application is complete; meantime, you might want to add a task to your Task List
as a reminder of this.
Now let's move onto the class itself. We'll modify the class to internal. As we discussed earlier, this
modification helps ensure that other developers using this application do not accidentally call the
Receive class:
internal class Pickup
Now here's the Execute() method:
public void Execute(string docID) {

Thread thread = new Thread(
new ThreadStart(new PickupAndProcess(docID).Execute));
thread.IsBackground = false;
thread.Start();
}
By setting the thread's IsBackground property to false, we prevent it from dying prematurely in the
event of the untimely death of a parent thread. Thus, if ReceiveDocument encounters severe
difficulties, ProcessDocument may still complete its task. With a simple line of code we further
enhanced NOP's reliability!
The Execute() method ultimately initiates the all-important ProcessDocument, our yet-to-be-built
order processing application, via a .NET thread object.
We're paying particular attention to how we created this thread object, ensuring each thread "keeps to
itself" throughout its lifetime. (The last thing we need is for an instance of one ProcessDocument to
get mixed up with another instance!) We accomplish this feat by including an inner class within Pickup
that is instantiated with each new thread.
Inner classes are another one of those cool object-oriented features .NET provides developers. By
placing an entire class inside of another class and modifying its accessor to private, only that
outer class can instantiate it. This feature comes in handy when developers need a specialized class
that only the outer knows about – like in our case!
The heart of the Pickup class lies buried deep within its inner class, PickupAndProcess. Aside from
housing the necessary state data (docID), it contains the real Execute method:
private class PickupAndProcess {
string m_DocID = string.Empty;
public PickupAndProcess(string docID) {

m_DocID = docID;
}
153
Chapter 3
public void Execute() {

string xmlText = string.Empty;
MessageQueueTransaction msqTrx = new MessageQueueTransaction();
OrderManager manageOrder = new OrderManager();
msgQueue = QueueManager.GetQueue();
msgQueue.Formatter = new BinaryMessageFormatter();
try {
msqTrx.Begin();
msgDoc = msgQueue.ReceiveById(m_DocID, msqTrx);
xmlText = msgDoc.Body.ToString();
manageOrder.Load(m_DocID, xmlText);
msqTrx.Commit();
}
catch {
msqTrx.Abort();
}
finally {
msgQueue.Close();
}
}
}
The above try...catch makes the dream of reliability come true in NOP. With the assistance of our
transactional queue we are able to ensure the safety of our original order in the event of a mishap within
the ProcessDocument application. For example, if ProcessDocument fails for some reason, the
source order returns to the queue via the msgTrx.Abort method. Otherwise, if all goes well, the queue
happily gives up the message via msgTrx.Commit.
One last noteworthy point about the Execute() method – it does not return any values and the thread
calling it does not wait for any news to come back. This behavior allows NOP to quickly return the
required synchronous HTTP response to end users without waiting for the potentially time-consuming
manageOrder.Load operation to finish.
If you're building the application for yourself as you step through this chapter, and you're feeling
adventurous, you could take a break now and test your work. Note that in this test scenario, if
everything works OK the inbounddocuments queue will be empty. Don't forget to either delete the
queue or purge the messages – otherwise, the earlier message will still be sitting there in the queue.
The ProcessDocument Application

The client test utility, TestHarness, and the "Store and Forward" application, ReceiveDocument, are
done. It is now finally time to build NOP's brains – the ProcessDocument class library. And while
there are quite a few classes inside this application, they are easily categorized by function. At the
highest level they either process documents or manage processing.
While we have already seen much of the class diagrams for this application, a quick peek at the
application's eventual references and files may be instructive:
154
To begin the process of building this application, add a new C# class library project called
ProcessDocument to the solution. Don't forget to add the necessary application references, as shown
under the References node in the above screenshot. (Unfortunately, one of them, the OrderManagement
application, remains a twinkle in our eye; we'll omit that one for now and return to add it later.)
Document Processing with the Decorator Pattern

There are several classes that take part in processing a document, as
the class view right amply demonstrates. Nonetheless, processing is
coordinated via a single Decorator pattern! In our application, create
a class file called ProcessDocument.cs – this will contain most of
those interfaces and classes that make up the skeleton of the
Decorator. The remaining classes implement the different business
rules as discussed in the Business Rules section, later in this chapter.
Before diving into the class definitions in ProcessDocument.cs, let's add some using statements.
There are few new ones this time around – System.IO and System.Xml.Schema. The IO class helps
when we are manipulating the XML string-formatted data via the StringReader class, while
XML.Schema assists with XML document validation:
155
Chapter 3
using System.IO;
using System.Xml;
using System.Xml.Schema;
Now let's get onto the class definitions. There will be three classes and an interface in
ProcessDocument.cs – ProcessDocument, Document, Processes, and DocumentRoles.
Some readers may find it disconcerting to put all these classes into a single file. It is certainly hard
to argue with the logic of simplicity – one class/interface, one file. Nonetheless, I feel that putting all
of the Decorator pattern's "fixed" code in one file is extremely logical. If you disagree, feel free to put
them anywhere you like!
The ProcessDocument Interface

Since the ProcessDocument interface sets the Decorator's rules for all constituent classes, that's a great
place to start. These methods and properties were discussed in greater depth in our earlier discussion
about NOP's class diagrams:
public interface ProcessDocument {

void Load(DocumentCodes.Type docType, string docID, string xmlText);
string DocID {get;}
XmlDocument DocXML {get;}
DocumentCodes.Type DocType {get; set;}
DocumentCodes.Status DocStatus {get; set;}
string DocErrors {get; set;}
}
The Document Class (the Decorator Pattern's Concrete Class)

The Document class implements these rules. It is the "concrete" class of the decorator for good reason –
it manufactures the object that the other class decorates. Let's step through its implementation:
public class Document : ProcessDocument {

private DocumentCodes.Type m_DocType = DocumentCodes.Type.Unknown;
private DocumentCodes.Status m_DocStatus = DocumentCodes.Status.Processing;
private string m_DocErrors = string.Empty;
private string m_DocID = string.Empty;
private XmlDocument m_Xml = new XmlDocument();
The DocumentCode.Type and DocumentCodes.Status enumerations reside in a helper

class entitled DocumentCodes, which we will visit shortly.
While most of the following routines work as simply as they appear, the Load() method kicks off the
critical task of sucking up the string formatted XML order document into the application as a certified
.NET XMLDocument object:
public void Load(DocumentCodes.Type docType, string docID, string xmlText) {

m_DocType = docType;
m_DocID = docID;
LoadXMLDoc(xmlText);
}
156
public string DocID {

get { return m_DocID; }
}
public XmlDocument DocXML {

get { return m_Xml; }
}
public DocumentCodes.Type DocType {

get { return m_DocType; }
set {
if( DocumentCodes.Type.Unknown == m_DocType )
m_DocType = value;
}
}
The DocStatus and DocErrors properties (which follow in a moment) work in combination to ensure
that a "broken" document does not subsequently get "fixed". This type of error is particularly endemic
of Decorator patterns. This becomes apparent when we consider how a "basic" Decorator pattern
manipulates the concrete class:
interface
Document
Concrete Decorator
DocumentDecoratorA DocumentDecoratorB DocumentDecoratorC
In the diagram above, suppose the Concrete class creates a docX object. DocumentDecoratorA then works
on docX, followed by DocumentDecoratorB, and DocumentDecoratorC. Suppose you wrote an application
based on this pattern – despite the obvious possibility that any of these classes could break docX, this
wouldn't worry you. (You just wrote them!) But suppose that, after a few months, another developer
comes along and adds a new DocumentDecoratorD class.
Suppose further that the DocumentDecoratorD developer did not really understand your brilliant
application, and that his new class can validate a docX property that DocumentDecoratorB occasionally
invalidates. The application would then sometimes validate a docX object when it is actually invalid. As
a result, the application would be broken.
If the Concrete class had included an irreversible flag in docX, then this sad tragedy could have been
avoided. For once DocumentDecoratorB invalidated docX, DocumentDecoratorD could not undo this fact.
So, there is a moral to this story. Namely, an irreversible flag (or similar safeguard) is highly
recommended with a Decorator, since too many classes have access to the underlying concrete object.
Here's the implementation of the DocStatus property:
157
Chapter 3
public DocumentCodes.Status DocStatus {

get { return m_DocStatus; }
set {
if( DocumentCodes.Status.Errors != m_DocStatus )
m_DocStatus = value;
}
}
And here's the DocErrors property:
public string DocErrors {

get { return m_DocErrors; }
set {
m_DocErrors += value + Environment.NewLine;

m_DocStatus = DocumentCodes.Status.Errors;
}
}
Note that, aside from providing a way to place errors inside a Document object, DocErrors also sets
the "document broken" flag. Why make a developer write two lines of code to register an error?
The private LoadXMLDoc() method implements ProcessDocument's most important function,

loading an XMLDocument object into the class variable m_Xml. Along the way it provides some helpful
XML validation services:
private void LoadXMLDoc(string xmlText) {
The next few lines, in conjunction with the XMLValidationEventHandler routine, validate the entire
XML document line by line. Setting the XMLValidator.ValidationType as we do here keeps things
simpler by making schema validation automatic – otherwise, the ValidationType property must be
set manually (and correctly) for each document. This cool feature works well in our application given
that our XML documents are not too complex and only use XMLValidator's built-in validation types:
ValidationEventHandler xmlEventHandler =
new ValidationEventHandler(ValidationCallback);
try {
StringReader stringReader = new StringReader(xmlText);
XmlTextReader xmlReader = new XmlTextReader(stringReader);
XmlValidatingReader xmlValidator = new XmlValidatingReader(xmlReader);

xmlValidator.ValidationType = ValidationType.Auto;
xmlValidator.ValidationEventHandler += xmlEventHandler;
while (xmlReader.Read()) {}
The while loop seems worthless, but in fact it quietly reads each line of XML, firing the
XMLValidationEventHandler whenever it discovers a validation error. (It could fire for every line in
the document!) If we don't run the XML document through this loop, it will not get fully validated.
Neither the .NET XmlTextReader nor XmlValidatingReader classes automatically validate
documents. (In fact, XmlTextReader cannot validate at all!) And we sure want to take advantage of our
DTDs and XSDs.
158
The while control loop works so well because of the design of the xmlValidator.Read
method. It returns False when there aren't any nodes left to read.
Now, why bother loading our class's XMLDocument object if the validation failed? ProcessDocument will
not be able to do its job without a valid document. So we check for errors before loading the document:

m_Xml.LoadXml(xmlText);
}
Recording the errors for the client's information is the only reasonable thing left to do:
DocErrors = ex.Message;
}
}
}
The final method serves as XMLValidator's callback defined via xmlEventHandler. It is referenced
via the ValidationEventHandler statement we saw a moment ago in the DocErrors(). It does the
actual job of placing any validation errors discovered while loading the XMLDocument object into a
Document object:
void ValidationCallback(object sender, ValidationEventArgs args) {

DocErrors = args.Message;
}
}
The Processes Class (the Decorator Pattern's Decorator Class)

The next class sitting on ProcessDocument.cs is the Decorator pattern's decorator class, Processes.
While this class cannot be instantiated directly, it contains references to routines that its subclasses may
require. All of these references are provided courtesy of a Document member object called m_Document:
public abstract class Processes : ProcessDocument {

protected ProcessDocument m_Document = null;
The class varaible modifier, protected, offers just the right amount of visibility for the decorator. It allows
m_Document to be accessible only from within the Processes class or from its decorator subclasses.
Here's the decorator class's default constructor:
public Processes(ProcessDocument doc) {

m_Document = doc;
}
The following methods constitute an excellent example of the powers of an object-oriented language.
They exploit containment and inheritance simultaneously! For example, look at the Load() method.
All the decorator subclasses can load an XML document and process it since they can instantiate a
Document object via the Processes class. And the reason Processes.Load() can execute the
Document.Load() method is because it contains a Document object:
159
Chapter 3
public void Load(DocumentCodes.Type docType, string docID, string xmlText) {

m_Document.Load(docType, docID, xmlText);
}
public string DocID {

get { return m_Document.DocID; }
}
public XmlDocument DocXML {

get { return m_Document.DocXML; }
}
public DocumentCodes.Type DocType {

get { return m_Document.DocType; }
set { m_Document.DocType = value; }
}
public DocumentCodes.Status DocStatus {

get { return m_Document.DocStatus; }
set { m_Document.DocStatus = value; }
}
public string DocErrors {

get { return m_Document.DocErrors; }
set { m_Document.DocErrors = value; }
}
}
The DocumentCodes Class

The next and final class sitting in ProcessDocument.cs is the DocumentCodes class. Technically
speaking, this class is not part of the Decorator pattern. Rather, it simply contains the enumerations for
the Status and Type properties of a document. By putting these enumerations into a class of their
own, we succeed in keeping the code more robust and well organized:
public class DocumentCodes {

public enum Status {
Processing,
Errors,
Complete
}
public enum Type {

Unknown,
SpecialOrder,
Order
}
}
The Business Rules

We are now ready to code with the four decorator classes (ValidateDocument, CheckInventory,
CheckCredit, and OrderProduct) that mirror the key activities detailed within the Primary Activity
Diagram. Together they encompass the business rules for which the Northwind Order Processing was
built. Some of them will call upon the services of other applications or classes to get their "business"
done. All of them are subclasses of the "decorator" class, Processes.
160
Before we get going, all of the decorator subclasses rely on .NET XML services, so do not forget the
following statement on the top of each C# file! (Note: OrderValidationStrategy actually performs
ValidateOrder's XML work, so you can skip this line on ValidateOrder.cs.)
using System.Xml;
Implementing the Strategy Pattern: the ValidateDocument Class

By far the most complicated of our business rule classes, ValidateDocument must intelligently deal
with at least two different types of order validation. This requirement was not a surprise given the two
different Validation Activity diagrams. It must be flexible for two reasons:
❑ Order validation business rules are subject to a great deal of ongoing change
❑ The underlying XML documents may use different XML validation rules (DTD, XDR, XSD,
and so on)
The solution to this potentially ugly design problem comes via the Strategy design pattern. It inherently
provides the necessary flexibility to call (and change!) the validation code without a lot of hassle. A
quick review of a portion of the ProcessDocument class diagram will help clarify this point:
ValidateDocument
+New()
interface
OrderValidationStrategy
+IsValid()
+ValidationErrors()
ValidateSpecialOrder ValidateOrder
+IsValid() +IsValid()
+ValidationErrors() +ValidationErrors()
+New() +New()
The interface, OrderValidationStrategy, provides the muscle of the Strategy pattern. It guarantees
that the decorator class, ValidateDocument, does not need to worry about the services
ValidateSpecialOrder and ValidateOrder offer. These two validation subclasses will always offer
the required methods. How they implement them is of little concern to ValidateOrder.
That ValidateOrder may remain oblivious of validation details provides a tremendous failsafe
mechanism as Northwind's order processing business requirements change. Future developers may
successfully break ValidateOrder or ValidateSpecialOrder, but the ProcessDocument
application rests safely! (True, letting bogus orders through the system will not make some folks too happy.)
161
Chapter 3
We'll start with the simplest of the depicted classes – ValidateDocument. Create a new class file,
ValidateDocument.cs, and insert the following code into it:
public class ValidateDocument : Processes {

public ValidateDocument(ProcessDocument doc): base(doc) {
if( DocumentCodes.Status.Errors != doc.DocStatus ) {
OrderValidationStrategy valid = null;
switch( doc.DocType ) {
case DocumentCodes.Type.SpecialOrder:
valid = new ValidateSpecialOrder(doc.DocID, doc.DocXML);
break;
case DocumentCodes.Type.Order:
valid = new ValidateOrder(doc.DocID, doc.DocXML);
break;
}
if( false == valid.IsValid() )

doc.DocErrors = valid.ValidationErrors();
}
}
}
The simple switch statement contains the key logic, deciding which OrderValidationStrategy
concrete class is called upon. It is worth noting that if we had not implemented the Strategy pattern, this
piece of decision logic code would have been huge! All of the validation code we are about to write
would have been sitting in it (or in nearby methods).
The OrderValidationStrategy Interface

Any Strategy pattern's success hinges on its interface. That way, its classes stay "honest" and work
without dire consequences when any of them are called upon. Our OrderValidationStrategy is no
exception to this.
We'll create a class file called OrderValidationStrategy.cs file, and add the
OrderValidationStrategy interface and the concrete strategy classes to it. The first thing to add is
an Imports statement for the System.Xml namespace:
using System.Xml;
Now, here's the OrderValidationStrategy interface:
public interface OrderValidationStrategy {

bool IsValid();
string ValidationErrors();
}
The ValidateSpecialOrder Concrete Class

With the Strategy pattern interface defined, let's write the class that validates a "Special Order"
document. If you remember the Validation Activity Diagram, then what we are inspecting should be
quite straightforward:
162
internal class ValidateSpecialOrder : OrderValidationStrategy {

bool m_IsValid = true;
string m_ValidationErrors = string.Empty;
public ValidateSpecialOrder(string docID, XmlDocument doc) {

int productID = 0;
double price = 0;
int quantity = 0;
XmlNodeList productNodes = null;
try {
productNodes = doc.GetElementsByTagName("Product");
My first crack at writing this algorithm taught me an interesting lesson. I discovered the importance of
making sure that there were some Product nodes to inspect! Under dubious circumstances
GetElementsByTagName("Product") may not return anything. For this reason, we include the
following check on the number of nodes:
if( 0 == productNodes.Count ) {
m_IsValid = false;
m_ValidationErrors = "Order validation failed; " +
"No product lines identified";
}
With the preliminaries out of the way, it's time to start moving through the order line by line:
for( int i = 0; i <= productNodes.Count - 1; i++ ) {
The next test is an example of a business rule-required validation check that a DTD could not provide
and an XSD could. DTDs are not very adept at checking numeric values, so we need to do the job:
productID = Int32.Parse(productNodes[i].Attributes[0].Value );
for( int j = 0; <= productNodes[i].ChildNodes.Count -1; j++ ) {

if( "Price" == productNodes[i].ChildNodes[j].Name )
price = double.Parse(productNodes[i].ChildNodes[j].InnerXml);
else if( "Quantity" == productNodes[i].ChildNodes[j].Name)
quantity = int.Parse(productNodes[i].ChildNodes[j].InnerXml);
}
if( productID < 0 ) {

m_IsValid = false;
m_ValidationErrors += "Unrecoginized ProductID: " +
productID + Environment.NewLine;
}
if( price < 0 || quantity < 0 ) {

m_IsValid = false;
m_ValidationErrors += "Negative price/quantity " +
"information submitted for ProductID = " +
163
Chapter 3
}
}
}
catch( InvalidCastException ex ) {
m_IsValid = false;
m_ValidationErrors += "Invalid product data submitted: " + ex.Message;
}
string msg = "Unable to validate order data for DocID = " + docID;
}
}
Comparison between this one method and its counterpart in the ValidateOrder class (which follows)
reinforces the decision to implement a Strategy pattern. The method above is really just a big algorithm
for reading and testing a Special Order. The Order's version (as you'll see) does not look much
different. Nonetheless, the algorithms turn out to be sufficiently different to justify their own class, as
opposed to some gigantic and fragile switch statement.
Here's the rest of the ValidateSpecialOrder class:
public bool IsValid() {

return m_IsValid;
}
public string ValidationErrors() {

return m_ValidationErrors;
}
}
The ValidateOrder Concrete Class

The run-of-the-mill "Order" looks a lot like the "Special Order" validation class. Of course, it worries
about a slightly different set of business rules. We'll highlight the differences as we go:
internal class ValidateOrder : OrderValidationStrategy {

bool m_IsValid = true;
string m_ValidationErrors = string.Empty;
public ValidateOrder(string docID, XmlDocument doc) {

int productID = 0;
double price = 0;
DateTime requiredDate = DateTime.Now.AddYears(-1);
try {
productNodes = doc.GetElementsByTagName("Product");
if( 0 == productNodes.Count ) {
m_IsValid = false;
m_ValidationErrors = "Order validation failed; " +
"No product lines identified";
}
164
for( int i = 0; i <= productNodes.Count -1; i++ ) {

productID = Int32.Parse(productNodes[i].Attributes[0].Value );
if( productID < 0 ) {

m_IsValid = false;
m_ValidationErrors += "Unrecognized ProductID: " + productID +
}
Unlike a Special Order, we did not have to verify that the productID was an Integer – the .NET
XmlValidatingReader did that already! So we check it here by making sure it is a positive integer.
for( int j = 0; j <= productNodes[i].ChildNodes.Count -1; j++ ) {

if( "Price" == productNodes[i].ChildNodes[j].Name )
else if("RequiredDate" == productNodes[i].ChildNodes[j].Name)

requiredDate = DateTime.Parse(productNodes[i].ChildNodes[j].InnerXml);
}
Since Order documents do not worry about quantity, we only have to check price for them:
if( price < 0 ) {

m_IsValid = false;
m_ValidationErrors += "Negative price information submitted " +
"for ProductID = " + productID +
}
Here's another validation check unique to an Order document. Special Orders do not have a
RequiredDate property to contend with:
if( requiredDate.CompareTo(DateTime.Now) < 0 ) {

m_IsValid = false;
m_ValidationErrors += "Invalid required due date " +
"information submitted for ProductID = " +
}
}
catch( InvalidCastException ex ) {
m_IsValid = false;
m_ValidationErrors += "Invalid product data submitted: " + ex.Message;
}
string msg = "Unable to validate order data for DocID = " + docID;
}
}
165
Chapter 3
public bool IsValid() {

return m_IsValid;
}
public string ValidationErrors() {

return m_ValidationErrors;
}
}
The CheckInventory Class

Through .NET COM Interop services, CheckInventory makes calling upon the legacy Inventory
system via the LegacyWrapper application a snap, but despite this "code saver" we still need to write
code that loops through the XMLDocument. Let's create a file called CheckInventory.cs and start
adding the following code:
using System.Xml;
using LegacyWrapper;
Read on if you are wondering why we imported System.Threading. All will become clear. Here's the
CheckInventory class:
public class CheckInventory : Processes {

public CheckInventory(ProcessDocument doc): base(doc) {
int productID = 0;
double price = 0;
int quantity = 0;
Thread.CurrentThread.ApartmentState = ApartmentState.STA;
Here's why we needed System.Threading. Setting the currently running thread's apartment state to
STA (single-threaded apartment) may help improve performance. Since we know that the underlying
COM application, the VB6-based Inventory.dll, runs as a single-threaded apartment, we prevent
.NET from first trying to run it any other way.
ProductInventory m_Inventory = new ProductInventory();
After creating the reference to Inventory.dll, accessing it is as simple as declaring the

variable m_Inventory!
try {
productNodes = doc.DocXML.GetElementsByTagName("Product");
if( 0 == productNodes.Count )
doc.DocErrors = "Can not check inventory; " +
"no product lines identified.";
for( int i = 0; i <= productNodes.Count -1; i++ ) {

productID = int.Parse(productNodes[i].Attributes[0].Value);
166
for(int j = 0;j<= productNodes[i].ChildNodes.Count-1; j++ ) {

if("Price" == productNodes[i].ChildNodes[j].Name)
else if("Quantity" == productNodes[i].ChildNodes[j].Name)
}
We make our first of two calls to the legacy Inventory application – checking whether or not the
product price submitted by the customer is correct:
if( !m_Inventory.CheckProductPrice((short)productID, price) )

doc.DocErrors = "Product ID #" + productID +
" is improperly priced.";
Now we make sure that the product is in stock:
if( m_Inventory.UnitsInStock((short)productID) < quantity )

doc.DocErrors = "Product ID #" + productID +" out of stock";
}
}
string msg = "Unable to check inventory for DocID = " + DocID;
}
}
}
The CheckCredit Class

The CheckCredit class really is too simple. While I kept the business rules quite simple for this
demonstration application, credit checking is an entire industry. Here we will just make sure that the
order's total sales amount doesn't exceed a constant value (MAXIMUM_ORDER_TOTAL). This code goes
into a new class file called CheckCredit.cs:
using System.Xml;
public class CheckCredit : Processes {

private const double MAXIMUM_ORDER_TOTAL = 500D;
public CheckCredit (ProcessDocument doc): base(doc) {

double price = 0;
int quantity = 0;
double totalOrder = 0;

try {
productNodes = doc.DocXML.GetElementsByTagName("Product");
if( 0 == productNodes.Count )
doc.DocErrors = "Can not check credit; " + "no product lines identified.";
167
Chapter 3
for( int i = 0; i <= productNodes.Count - 1; i++ ) {

for(int j = 0; j<= productNodes[i].ChildNodes.Count-1; j++) {
if("Price" == productNodes[i].ChildNodes[j].Name)
else if("Quantity" == productNodes[i].ChildNodes[j].Name)

}
totalOrder += price * quantity;

}
if( totalOrder > MAXIMUM_ORDER_TOTAL )

doc.DocErrors = "Total Amount of order exceeds " + MAXIMUM_ORDER_TOTAL;
}
string msg = "Unable to check credit for DocID = " + DocID;
}
}
}
}
The OrderProduct Class

If everything goes well, the OrderProduct class places an order into Northwind's order system. We'll
put this code into another new class file, OrderProduct.cs.
Since the OrderManagement application to do that does not exist yet, we need to comment out its
references for the moment. The OrderManagement application is responsible for actually placing
orders. When we are finished with ProcessDocument, we will finally build the OrderManagement
application, which is responsible for actually placing orders. Then, we'll come back to this application
and reinstate the commented-out lines:
//using OrderManagement
Now for the class itself:
public class OrderProduct : Processes {

string m_OrderID = string.Empty;
As long as the other business classes did not generate any errors, the order gets placed via the Place()
method call in the constructor:
public OrderProduct(ProcessDocument doc) : base(doc) {

Place place = new Place();
m_OrderID = place.NewOrder(doc.DocXML);
if( m_OrderID.Length > 0 )

doc.DocStatus = DocumentCodes.Status.Complete;
}
}
168
Unlike the other business rule classes, we included a method other than New(). Adding methods and
properties to a Decorator pattern's derived class is normal. One of the reasons that it is so common is
the very same reason we added a property here – we needed to obtain information from the class. In
our case, we wanted to make the newfound m_OrderID available outside of OrderProduct:
public string GetOrderID() {

return m_OrderID;
}
}
There are many other reasons for adding additional routines to a decorator beyond public access to a
variable. Remember what the Decorator aims to accomplish – attaching additional responsibilities, and if
you add additional responsibilities to a class, you will most likely need to give clients access to them.
The Processing Manager – the OrderManager Class

The "processing manager" classes worry about one thing – managing how documents are processed.
That essentially translates into how the different decorators' derived classes are applied, if at all! This
function becomes critical when utilizing the Decorator design pattern since the pattern by its very
nature offers a wide variety of processing options. For example, a regular "Order" passes through the
CheckCredit class, while "Special Order" documents do not.
The official GoF Decorator pattern does not mandate a "managing class". Nonetheless, I have
learned through experience that using one prevents misuse of a decorator's derived classes.
Since our application worries about orders, we only need one of these specialized classes –
OrderManager. Some readers may question why we bother with an OrderManager class. Couldn't we
just bury the code that builds the appropriate decorators somewhere else? Of course, we could but doing
so limits the ease of updating NOP. For example, suppose Northwind decides to allow customers to place
order inquiries and cancellations. Where would the developer responsible for implementing these features
begin? Maybe check the client code? How about the decorator? If the decorator, where? Will I break any
other applications when I add the new derived classes supporting the additional responsibilities?
Like a good manager, our "processing manager" class keeps everyone informed. It accomplishes this
with the same status message system we discussed earlier. Placing the code responsible for inserting
status messages in the NWindOrderStatus database in OrderManager offers another advantage – it
does not "pollute" the business rules classes with unrelated activity.
Create another new class file, called OrderManager.cs, to the ProcessDocument application. Now
we can start to add code to it. First, here are key using references we'll need:
using System.Data;
using System.Data.SqlClient;
Now here's the OrderManager class. Again, if your SQL Server instance is not hosted on your
LocalHost machine, then you may need to change the server attribute here to reflect that:
public class OrderManager {

private const string CONNECT_STRING =
"server=Localhost;uid=DocWrox;database=NWindOrderStatus";
169
Chapter 3
Here's the class's Load() method. Its first call to SetStatus() allows the curious customer to find out
that their submitted order is being processed:
public void Load(string docID, string xmlText) {

string statusField = string.Empty;
string docType = string.Empty;
OrderProduct order = null;
SetStatus(docID, DateTime.Now.ToString() + " Processing");
Instantiating doc, the decorator's concrete object, starts the ball rolling! Then we use some simple
if...else clauses to decide how to decorate doc. Remember that NOP possesses two different order
types, which require slightly different processing by the same components:
Document doc = new Document();
if( xmlText.IndexOf("SpecialOrder.dtd") > 0 ) {

doc.Load(DocumentCodes.Type.SpecialOrder, docID, xmlText);
order = new OrderProduct(new CheckInventory(new ValidateDocument(doc)));
}
else if ( xmlText.IndexOf("Order.xsd") > 0 ) {
doc.Load(DocumentCodes.Type.Order, docID, xmlText);
order = new OrderProduct(
new CheckCredit(
new CheckInventory(
new ValidateDocument(doc))));
}
else {
string msg = "Unknown document type of " + docType +
" for DocID = " + docID;
}
There are many ways to decide what XML document is being sent to NOP. Using the document's
referenced validation schema though does have an advantage. It almost guarantees that inbound XML
documents are routed appropriately. We could improve these odds for XSD documents by searching for
a fully qualified URI, such as http://NorthwindTraders.com/Order.xsd:
switch( order.DocStatus ) {
case DocumentCodes.Status.Errors:
statusField = DateTime.Now.ToString() + " Errors:" +
Environment.NewLine + order.DocErrors;
break;
case DocumentCodes.Status.Complete:
statusField = "Order ID: " + order.GetOrderID();
break;
default:
statusField = DateTime.Now.ToString() +
" Processing Incomplete";
break;
}
170
Our last call to SetStatus() hopefully contains good news – a submitted order's OrderID, for the
curious customer:
statusField = statusField.Replace("'","");
SetStatus(docID, statusField);
}
And here is the SetStatus() method:
private void SetStatus(string docID, string Status) {

string sql = string.Empty;
SqlConnection cn = null;
SqlCommand cmd = null;
sql = "INSERT DocumentStatus (DocumentID, Status) VALUES(";

sql += "'" + docID + "'";
sql += ", ";
sql += "'" + Status + "'";
sql += ")";
try {
cn = new SqlConnection(CONNECT_STRING);
cmd = new SqlCommand();
cmd.CommandType = CommandType.Text;
cmd.CommandText = sql;
cmd.Connection = cn;
cn.Open();
cmd.ExecuteNonQuery();
}
string msg = "Unable to save status(" + Status + ") for DocID = " + docID;
}
finally {
if( cn.State != ConnectionState.Closed )
cn.Close();
}
}
}
Testing the ProcessDocument Application

Now is a good time to test what's been written so far. If you haven't done so already, you'll need to go
back and complete all those outstanding tasks:
❑ In the TestHarness project, ensure you've reinstated the four lines in frmMain.cs that refer
to ReceiveDocument.Receive. Also make sure TestHarness has a reference to the
ReceiveDocument project.
❑ In the ReceiveDocument project, reinstate the two lines in Receive.cs that refer to
ReceiveDocument.Pickup.
171
Chapter 3
❑ Also, in the ReceiveDocument project, reinstate the three lines in Pickup.cs that refer to
ProcessDocument.OrderManager. Also make sure ReceiveDocument has a reference to
the ProcessDocument project.
Compile the solution, run TestHarness.exe, and submit a few orders. You probably won't see the
messages in the inbounddocuments queue in the MMC, because they pass through too quickly.
However, you should begin to see the order status entries appear in the DocumentStatus table of the
NWindOrderStatus database:
OrderManagement
This little application provides the last service NOP requires before we can finish up. It will just place
orders into the Northwind Order system. This task only requires placing the order in a specific MSMQ
NewOrder queue. We'll add one more application with two classes: SimpleQueueManager and Place.
After adding a C# class library project entitled OrderManagement to the solution, add a reference to
System.Messaging.dll. Also, remove the default class file Class1.cs. Now we're ready to add our
two new classes.
The SimpleQueueManager Class

Add a new class file called SimpleQueueManager.cs, and add the following code to it:
internal class SimpleQueueManager {

private const string QUEUE_NAME = "NewOrders";
public static MessageQueue GetQueue()

string msgQueueName = ".\\private$\\" + QUEUE_NAME;
if( MessageQueue.Exists(msgQueueName) ) {
try {
msgQueue = new MessageQueue(msgQueueName);
}
}
}
else {
try {
msgQueue = MessageQueue.Create(msgQueueName);
}
172
string msg = "Unable to create the " + QUEUE_NAME + " queue";
}
}
return msgQueue;
}
}
The Place Class

Next, add a class file called Place.cs, and then add the Place class detailed below. It provides the
only public method, NewOrder(), in the OrderManagement application:
public class Place {

public string NewOrder(XmlDocument xmlDoc) {
string orderID = string.Empty;
MessageQueue msgQueue = SimpleQueueManager.GetQueue();
msgDoc.Label = "Order " + DateTime.UtcNow.ToString();

msgDoc.Body = xmlDoc.InnerXml;
try {
msgQueue.Send(msgDoc);
orderID = msgDoc.Id;
}
string msg = "Unable to send order to the " + msgQueue.QueueName + " queue";
}
finally {
msgQueue.Close();
}
orderID = "NW000" + orderID.Remove(0, orderID.LastIndexOf("\\") + 1);
return orderID;
}
}
There is one small point worth observing before we move on to system testing. Until now, the returned
identification numbers existed to monitor a document's passage through the Northwind Order
Processing application. It is only here, at the very end of the drill, that the customer obtains a "real"
order identification number!
173
Chapter 3
System Testing
Speaking of testing, now we can test the entire system we've created. There are a couple of outstanding
tasks to complete:
❑ In the ProcessDocument project, ensure you've reinstated the three lines in

OrderProduct.cs that refer to OrderManagement.Place
❑ Make sure ProcessDocument has a reference to the OrderManagement project
Now compile the solution and run the TestHarness.exe application one last time. If everything ran as
hoped, your Computer Management MMC should contain something resembling the sample below:
This sample shows that two orders were submitted via the TestHarness application sitting in the
neworders queue. (If we inspect the inbounddocuments queue, it should be empty.)
Of course, you do not have to keep checking your queues to know whether orders arrived safely. After
submitting an order, we can use the DocumentID to obtain its status, which is now being recorded in
the DocumentStatus table of the NWindOrderStatus database:
174
By clicking the TestHarness's Check Order Status button, the txtCheckResult Order Status
control should display the order number:
Reference to
submitted
document
Final
Order ID
Summary
We built a middle-tier application capable of supporting a web service in this chapter. Northwind
customers will soon be submitting their orders via the web. Northwind sales representatives won't waste
any more time keying in orders.
Along the way, we incorporated several basic GoF patterns that contributed significantly to our
application's success. And while it is usually difficult to "pin the feature on the pattern", we can list a few
patterns and their contributions:
❑ The Singleton pattern enhanced performance in the ReceiveDocument application

❑ The Decorator facilitated the application of business rules within the ProcessDocument
application
❑ The Strategy pattern kept order validation flexible within the ValidateOrder class
❑ The Façade pattern simplified access to a legacy Inventory system
These design patterns will also facilitate implementing Northwind's inevitable business rule changes. This
is obvious with the ValidateOrder class, where the Strategy pattern eases any validation algorithm
changes. However, even the entire order processing procedures realizes greater flexibility with a design
pattern! The Decorator that it was built with inherently supports additional order responsibilities.
Finally, our application also demonstrated an implementation of the more complex Store and Forward
pattern, a perennial favorite of Internet-based business-to-business applications concerned with
reliability and performance. It also provided a nice demonstration of transactional MSMQ queues and
the .NET threading class.
175
Chapter 3
176

Wrox Professional C - Hash Design Patterns Applied PDF

Uploaded by

Copyright:

Available Formats

Wrox Professional C - Hash Design Patterns Applied PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Wrox Professional C - Hash Design Patterns Applied PDF

Uploaded by

Copyright:

Available Formats

What you need to use this book

❑ Windows 2000 Professional, Server or Advanced Server Edition; or Windows XP

This book assumes the following knowledge:

In summary, we'll see the following patterns in application in this chapter:

Analysis and Design

Use Case Diagrams

Order Processing VB 6 DLL

Status XML to MSMQ

Order Processing Action Effect of Action on Order Processing

Special Order Order

Inspect Product ID Code XML Validation

Order Processing Validate Special Order Validate Order

Validate Special Order Validate Order Inspect Product ID

Check Inventory Check Inventory Inspect Price Inspect Price

Check Credit Inspect Quantity

Order Product Order Product Inspect Date

❑ Intent of GoF Decorator: Attach additional responsibilities to an object dynamically.

❑ Intent of GoF Template Method: Define the skeleton of an algorithm in an operation,

The solution amounts to a two-step process:

:Client (Test Harness) :ReceiveDocument :ProcessDocument :LegacyWrapper :OrderManagement

XML String Persist XML

Document ID Check Inventory

The Decorator Pattern Classes

The Strategy Pattern Classes

The Final Class Diagram

ValidateDocument CheckInventory CheckCredit OrderProduct

The Coding Part

Setting up the Infrastructure

1. Register the "legacy" component Inventory.dll.

2. Verify (and, if required, install) the Windows MSMQ service.

4. Create a Visual Studio .NET solution.

In this section, we'll cover these four tasks.

Setting up the SQL Server Databases

The Northwind Database

The NWindOrderStatus Database

IF EXISTS (SELECT name FROM master.dbo.sysdatabases

CREATE DATABASE [NWindOrderStatus]

SIZE = 1, FILEGROWTH = 10%)

Creating a Visual Studio .NET Solution

The Legacy Application

VERSION 1.0 CLASS

Public Function InstockCount(ByVal ProductID As Integer) As Integer

strQuery = "SELECT UnitsInStock FROM Products WHERE ProductID = " & _

Public Function PriceCheck(ByVal ProductID As Long, _

On Error GoTo LocalError

strQuery = "SELECT * FROM Products WHERE "

Set cn = New ADODB.Connection

Set cn = New ADODB.Connection

Public Function GetConnectionString() As String

public class ProductInventory {

ProductClass m_Inventory = new ProductClass();

public bool CheckProductPrice(int productId, double price) {

if( result > 0 )

In the code above, our reinterpretation of m_Inventory.PriceCheck() now begins to look a

public int UnitsInStock(short productId) {

How the Façade Pattern is Helping Us

The Test Harness

Adding the Controls

Control Property Name Property Value