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 and 3) ❑ MSMQ (for Chapter 3) and IIS 5.0 (for Chapters 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 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 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 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 176 ... 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. .. 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... 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: