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.

Tip 

I used these arguments in my Visual Basic 6 Business Objects and Visual Basic 6 Distributed Objects books. They're reasonably valid and result in a perfectly workable architecture, but the end result isn't ideal it's far preferable to preserve encapsulation by having just one class. This wasn't practical in Visual Basic 6 and COM, but since .NET enables this approach, it's the one I pursued in the creation of CSLA .NET.

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 .