Chapter 2: Framework Design

Overview

In Chapter 1 we discussed some general concepts about physical and logical n-tier architecture, including a discussion of a 5-tier model for describing systems logically. In this chapter, we'll take that 5- tier logical model and expand it into a framework design. Specifically, we'll be mapping the logical tiers against the technologies illustrated in Figure 2-1.

Figure 2-1: Mapping the logical tiers to technologies

The framework itself will focus on the business-logic and data-access tiers. This is primarily due to the fact that there are already powerful technologies for building Windows, web, and mobile user interfaces and presentations. Also, there are already powerful data-storage options available, including SQL Server, Oracle, DB2, XML documents, and so forth.

Recognizing that these preexisting technologies are ideal for building the presentation and UI layers as well as for handling data storage allows us to focus on the parts of the application that have the least technological support, where the highest return on investment occurs through reuse. Analyzing, designing, implementing, testing, and maintaining business logic is incredibly expensive. The more reuse we can achieve, the lower our long- term application costs become. The easier it is to maintain and modify this logic, the lower our costs will be over time.

When I set out to create the architecture and framework discussed in this book, I started with the following set of high-level guidelines:

• Simplify the task of creating object-oriented applications in a distributed .NET environment.

• The Windows, web, and web services interface developer should never see or be aware of SQL, ADO.NET, or other raw data concepts, but should instead rely on a purely object-oriented model of the problem domain.

• Business object developers should be able to use "natural" coding techniques to create their classesthat is, they should employ everyday coding using variables , properties, and methods . Little or no extra knowledge should be required.

• The business classes should provide total encapsulation of business logic, including validation, manipulation, calculation, security, and data access. Everything pertaining to an entity in the problem domain should be found within a single class.

• Provide an n-tier logical architecture that can be easily reconfigured to run on one to four physical tiers.

• Use complex features in .NET, but they should be largely hidden and automated: remoting, serialization, security, no-touch deployment, and so forth.

• The concepts present in the framework I created for VB 6 should carry forward, including object-undo capabilities, broken-rules tracking, and object-state tracking ( IsNew , IsDirty , IsDeleted ).

• The framework in this book should be interchangeable with the one from Expert One-on-One Visual Basic .NET Business Objects . Switching between the two versions of the framework should be transparent.

In this chapter, we'll focus on the design of a framework that allows us to make use of object-oriented design and programming with these guidelines in mind. Once we've walked through the design of the framework, in Chapters 4 and 5 we'll dive in and implement the framework itself, focusing first on the parts that support UI development, and then on providing scalable data access and object-relational mapping for our objects. Before we get into the design of the framework, however, let's discuss some of the specific goals I was attempting to achieve.