a0006 wrox professional c design patterns applie morebook vn 3517

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
Chapter 1:
Chapter 2:
Chapter 3:
Chapter 4:
Chapter 5:
Chapter 6:
Appendix A:
Index

Introduction to Design Patterns
Design Patterns in the Data Tier
Design Patterns in the Middle Tier
Design Patterns in the Presentation Tier
Between the Tiers: Design Patterns and .NET Remoting
What Next?
UML Primer

1
9
67

117
177
257
299
309
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


Design Patterns in the Middle Tier

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


Design Patterns in the Middle Tier

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