Chapter 5: Data Access and Security

Overview

In Chapter 4, we combined the concepts from Chapter 1, the framework design from Chapter 2, and the technologies from Chapter 3 to create about half of the CSLA .NET framework. In this chapter, we'll continue the process, completing implementation of the remaining classes. This will entail making some minor changes to some of the classes we created in Chapter 4 as well.

Specifically, we'll create the following components , as discussed in Chapter 2:

• CSLA.Server.DataPortal.dll

• CSLA.Server.ServicedDataPortal.dll

And we'll need to add some methods to the base classes that can interact with our data access framework:

• BusinessBase

• BusinessCollectionBase

• ReadOnlyBase

• ReadOnlyCollectionBase

Also, we'll create a host application that will run on an application server to host the server-side DataPortal components. This will be a simple ASP.NET application that's configured to act as a .NET remoting host. We'll follow the same process here that we walked through in Chapter 3 when we introduced the concept of using IIS as a remoting host.

Once we've enabled data access within the business framework, we'll employ that functionality to create our custom security infrastructure. This will include the creation of principal and identity objects as part of the .NET security framework. It will also include their integration directly into the overall DataPortal mechanism, so that our business objects can have the same security context on the application server as they do on a client workstation or a web server.

Finally, we'll close the chapter by creating a generic list class to support almost any read-only name -value list. Not only is this type of object invaluableit's used by almost every applicationbut also it will give us a glimpse into how collection objects are populated through the DataPortal mechanism.

The classes we'll create in this chapter are as follows :

• TransactionalAttribute

• Server.DataPortal

• Server.ServicedDataPortal.DataPortal

• DataPortal (client-side class)

• Data.SafeDataReader

• Security.Principal

• Security.Identity

• NameValueList

The reasoning behind each of these classes, and how they are organized into namespaces and assemblies, was covered in Chapter 2. We'll be reprising those discussions as we work our way through this chapter.

A Note About Object-Oriented Programming

One of the primary goals of object-oriented programming is to encapsulate all the functionality (data and implementation) for a domain entity into a single class. This means, for instance, that all the data and implementation logic for the concept of a customer should be in a Customer class.

A corollary to this is that an object should avoid externalizing its data, so that other code can interact with that data. Anytime an object makes its internal data available to other code, the object loses control over that data. The end result is decreased maintainability and an increased likelihood of unexpected results, because we no longer are sure that all our business logic is contained within that single class.

It has always been difficult to achieve strong encapsulation at the same time as distributing an application over physical tiers. If the data access code must run on an application server, but the object must run on the client or web server, we've typically created two different classes. One class is the business object itself that runs on the client, while the other contains the data access code and runs on the application server.

By definition, this breaks encapsulation, since we have two different objects (the business object and the data access object) that both externalize their data. Now, we can argue that this isn't too bad, because they're only externalizing their data to each otherand we might even argue that the objects are two halves of the same "virtual" objectbut in the end, we are breaking encapsulation. We're also making maintenance more complex, because we now have business logic split between two classes, and we need to maintain it in both. We end up trying to avoid duplication of logic, and yet provide good performance and functionality.

A better solution is to preserve encapsulation entirely by keeping all of the business logic for an entity in a single class. This can be accomplished if it's practical to move the object physically from client to server and back again. As we discussed in Chapter 1, we can achieve this by making our business objects unanchored, so that they move from machine to machine. However, this also implies that we have an object that is anchored on the application server, so that our client-side code can pass our objects to it.

This requirement is the purpose behind the server-side DataPortal object. It acts as the anchored object on the application server, receiving business objects from our clients , as shown in Figure 5-1.

Figure 5-1: Client-side DataPortal calls server-side DataPortal

Once our object is physically on the server, it's the job of the server-side DataPortal to invoke the appropriate methods to create, retrieve, update, or delete the object's data. Remember that the data access code itself is inside our business object; the server-side DataPortal merely invokes the appropriate method.

On the client side, we also have a DataPortal object, which exists to simplify how the server-side DataPortal is called. Instead of writing the remoting code into each of our business objects, we can write it into a centralized, client-side DataPortal , and our business object code can use this more abstract mechanism to interact with the server-side DataPortal .