a0006 wrox professional c design patterns applie morebook vn 3517

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

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

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

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

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

Design Patterns in the Middle Tier

119

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.

By clicking the 's button, the

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

Chapter 3

176