Overview

In the previous chapter, we covered some patterns with what you could call "fungible" applicability, compared with the others in this book. This simply means that business- tier patterns can really be applied anywhere in your code. These patterns can reside on the client or on a server, or they can be interspersed among different distributed layers throughout your enterprise. However, they usually find themselves at the core of the business or middle layer, as presented in the implementation examples. In this chapter, data tier patterns derive from their use of stored data and are usually of commercial data stores such as SQL Server, Oracle, or even DB2.

Many times, the following patterns will be strictly found at a true data tier and can even be used to design an entire data management system or framework. They can be the "design" tools employed to develop a self-contained data management system or even a third-party product whose job is to provide data services in a generic way. The principles covered in this chapter really stand on their own and are offered only as an option for developing data layers. They can be used with more traditional data architectures in part or in their entirety. As you will see, this form of data access is a slight departure from the usual.

Many of the patterns in this chapter have a particular synergy with one another ”they feed off of each other. Each idea in this chapter is an island, but as a group , they also work cohesively as a single unit, or macropattern, if you will (not to be confused with the scriptlike code baked into old versions of Excel). In fact, many of these patterns have been implemented in the commercial application featured in Chapter 6 and should be running in a product at many of the Fortune 500 companies that bought the product by the time this book is published.

It doesn't matter whether an application is broken up into physical layers or not; the patterns covered here are focused on one common thing ”data management. It should be noted, however, that most of these patterns do not directly tie themselves with any one particular persistent data store. Whether data is stored at the file level or an enterprise database system is used, these patterns should help any developer design the routines to "get at" that data and present it in the most robust and reusable fashion. In fact, even though most of the patterns here have been implemented in C#, many of them can be considered technology- agnostic and can easily be implemented in other languages. This even applies to non-.NET languages such as Java (gasp!). That said, the implementation approach here does lean heavily on the some of the "XML magic" included in the .NET framework and on ADO.NET, in particular.

Some of this technology "magic," such as the use of XML schemas, will be covered in backgrounders throughout the chapter. I hope to show you why it is so powerful that Microsoft incorporated XML into its framework. Through these examples I hope to show XML in a whole new light and deliver on all of the capabilities alluded to over the past several years .

As before, each implementation example will keep with the general solution "theme" and use a financial processing application to drive the example code. We cover the following patterns and practices in this chapter:

• Poly Model (a "composite" pattern)

• Schema Indexer

• Schema Field

• Abstract Schema (using Abstract Packet)

• Poly Model Factory ( using Factory Method )

With important (and related ) mention to the following design patterns:

Factory Method (GoF)

Abstract Factory (GoF)

Fa §ade (GoF)

Abstract Packet (Thilmany)

Interface (GoF)

I hope you will find this chapter rather unique. Instead of diving into the typical "data best practices" you always seem to get, I've take a slightly different approach by relating each pattern as whole and giving you an entire data framework to work with. Although this approach is atypical, its benefits have already been noticed, and it is in production at my company as I write this. Take heed, it may take some patience to get the whole picture but once you complete this chapter, I hope you will understand what I'm talking about. Along the way, I will contrast the presented Poly Model with more traditional data practices. Even if you don't apply Poly Models directly in your code, you will still get a good idea of what XML power I've been speaking of through this book. It may even help you build a more traditional data access layer with a new outlook, allowing you to "think outside the box," even if that box is the same old data access layer.

Before I delve into each pattern, I first need to introduce the idea of XML schemas and their relationship to ADO.NET DataSets. Most of the patterns deal in some way or another with XML schemas, so unless you have extensive experience building type-strong DataSets in .NET, I suggest reviewing the following technology backgrounder. For those who haven't used XML schemas or even for those who are unfamiliar with how ADO.NET leverages off of XML schemas, the following section should help at least give you an overview of one of the most significant additions to ADO.NET.