Using CSLA .NET

The class diagrams that we've created so far have focused entirely on the business domainwhich is a good thing. Ideally, we should always start by focusing on business issues, and deferring much of the technical design to a later stage in the process. Users typically don't understand (or care about) the technical issues behind the scenes, such as how we're going to implement the Cancel buttons , or how we're going to retrieve data from the database.

Of course, we care about these issues, but they can be dealt with after the basic object modeling is complete, so that we have a good understanding of the business issues, and confidence that our model can meet the requirements laid out in the use cases.

In our case, we also have the significant advantage of having designed and built a business framework. What this means for us is that we don't need to spend time figuring out how to design or implement the features we've included in the framework. By relying on CSLA .NET, we gain the following information listed in Table 6-4.

Table 6-4: Automatic Benefits Gained by Using CSLA .NET

Feature	Description
Smart data	Business data is encapsulated in objects along with its associated business logic, so we're never working with raw, unprotected data, and all our business logic is centralized for easy maintenance.
Easy object creation	We use standard .NET object-oriented programming techniques to create business objects.
Flexible physical configuration	Data access runs locally or on an application server, without changing business code.
Object persistence	Clearly defined methods contain all data-access code.
Optimized data access	Objects only persist themselves if their data has been changed. It's easy to select between high-performance manual transactions, or two-phase distributed transactions for multidatabase updates. High-performance binary data transfer links between client and server.
Optional n-Level undo capabilities	Support for complex Windows Forms interfaces is easy, while also supporting high-performance web interfaces.
Business rule tracking	Reduces the code required to implement business rules.
Simple UI creation	With full support for both Windows Forms and Web Forms data binding, minimal code is required to create sophisticated user interfaces (see Chapters 8 and 9).
Web service support	We can readily create a web-service interface to our application, so that other applications can directly tap into both our data and our business logic with minimal effort on our part (see Chapter 10).
Role-based security	Makes it easy to select between Windows' integrated security and CSLA .NET's table-based security. It's also easy to customize CSLA .NET's table-based security to use preexisting security databases. Full compliance with standard .NET security objects.

To use CSLA .NET, we merely need to determine which base classes to inherit from as we create each of our business classes. For example, some of our business objects will be editable objects that can be loaded directly by the user. These need to inherit from BusinessBase as shown in Figure 6-11.

Figure 6-11: Business objects subclassing BusinessBase

By subclassing BusinessBase , all of these objects gain the full set of business object capabilities that we implemented in Chapters 4 and 5.

We also have some objects that are collections of business objects, and they should inherit from BusinessCollectionBase as shown in Figure 6-12.

Figure 6-12: Business objects subclassing BusinessCollectionBase

BusinessCollectionBase supports the undo capabilities that we implemented for BusinessBase the two classes work hand in hand to provide this functionality.

As shown in Figure 6-13, the two objects that list read-only data for the user inherit from ReadOnlyCollectionBase .

Figure 6-13: Read-only list objects subclassing ReadOnlyCollectionBase

This base class provides the support that our objects need for retrieving data from the database without the overhead of supporting undo or business-rule tracking. Those features aren't required for read-only objects.

Finally, we have the RoleList object, which is a read-only list of simple string data. Although we could implement this using ReadOnlyCollectionBase , we built a better alternative into the frameworkthe NameValueList class, as shown in Figure 6-14.

Figure 6-14: RoleList subclassing NameValueList

This base class is designed to make it as easy as possible to create read-only lists of text values, so it's ideal for when we build our RoleList class.

We'll implement all of these classes in Chapter 7. During that process, we'll see how to use the CSLA .NET Framework that we built earlier in the book to simplify the process of creating business objects.