Namespace Organization

At this point, we've walked through all the classes that will make up our business framework. Shortly, we'll discuss how to group them into components or assemblies, but first we should give some thought to the use of namespaces .

Namespaces allow us to group classes together in meaningful ways so that we can program against them more easily. Additionally, namespaces allow us to have different classes with the same name as long as they're in different groups. From a business perspective, we might use a scheme like the following:

 MyCompany.MyApplication.FunctionalArea.Class 

A convention like this immediately tells us that the class belongs to a specific functional area within an application and organization. It also means that we could have multiple classes with the same names :

 MyCompany.MyApplication.Sales.Product MyCompany.MyApplication.Manufacturing.Product 

It's quite likely that the concept of a "product" in sales is different from that in manufacturing, and this approach allows us to easily reuse class names to make each part of our application as clear and self-documenting as possible.

The same is true when you're building a framework. We want to group our classes in meaningful ways so that they're comprehensible to the end developer. Additionally, we want to help the end developer by putting little-used or obscure classes in separate namespaces, so the business developer doesn't typically see them via IntelliSense.

Consider our UndoableBase class, which isn't intended for use by a business developerit exists for use within our framework. Ideally, when a business developer is working with our framework, she won't see UndoableBase via IntelliSense unless she goes looking for it by specifically navigating to the namespace where we put it. To accomplish this, we can have some namespaces that are to be used by end developers, and others that are intended for internal use.

We'll prefix all our namespaces with component-based scalable, logical architecture (CSLA).

Note 

CSLA was the name of the COM-based business-object framework about which I wrote in the mid-to late '90s. In many ways, this book is an attempt to bring the basic concepts and capabilities of that architecture into the .NET environment. In fact, .NET enables the CSLA concepts, though COM often hindered them.

The following core objectsthe ones intended for use by business developers will go into the CSLA namespace itself:

 CSLA.NotUndoableAttribute      CSLA.BusinessBase      CSLA.BrokenRules      CSLA.RulesCollection      CSLA.Rule data type      CSLA.BusinessCollectionBase      CSLA.ReadOnlyBase      CSLA.ReadOnlyCollectionBase      CSLA.DataPortal      CSLA.TransactionalAttribute      CSLA.NameValueList      CSLA.SmartDate      CSLA.SafeSqlDataReader 

The UndoableBase class, which is for internal use only, will go into a separate namespace that won't typically be imported by business developers. This is also true of the BindableBase and BindableCollectionBase classes, which are primarily for internal use and shouldn't clutter the day-to-day coding of business developers:

 CSLA.Core.UndoableBase      CSLA.Core.BindableBase      CSLA.Core.BindableCollectionBase 

Following the lead of the .NET Framework itself, we'll group our security- related classes into their own namespace. This is useful because the business developer might choose to use Windows' integrated security rather than our custom security, and this approach means they'll only see these classes if they import this specific namespace:

 CSLA.Security.Principal     CSLA.Security.Identity 

Notice that we already have the client-side DataPortal class in the CSLA namespace, which makes sense because it's the client-side DataPortal that will be used by business developers. However, we've got two other DataPortal concepts that are used within our framework: the server-side DataPortal , and the transactional, serviced DataPortal . Here's where the ability to have duplicate names in different namespaces is ideal. We'll create namespaces for the server-side DataPortal classes to indicate their use:

 CSLA.Server.DataPortal     CSLA.Server.ServicedDataPortal.DataPortal 

The client-side DataPortal will use these two namespaces so that it can correctly invoke the transactional or nontransactional version of the DataPortal as appropriate.

The end result is that a typical business developer can simply use the CSLA namespace as follows :

 using CSLA; 

And all they'll see are the classes intended for use during business development. All the other classes and concepts within the framework are located in other namespaces, and therefore won't appear in IntelliSense by default unless the developer specifically imports those namespaces as well. If we're using the custom table-based security, we'll likely import the CSLA.Security namespace. But if we're not using that feature, we can ignore those classes and they won't clutter up our development experience.

Component Design

Now that we've seen the overall design and the classes that will comprise our business framework, we need to decide how to break them into components or assemblies. The framework will consist of a set of DLLs that can be referenced as we build our business objects and applications. The questions are as follows: How do we decide how many DLLs (assemblies) there should be, and what should go into each?

The thing to remember about an assembly is that it's a unit of deployment . We can't deploy classes or objects; we can only deploy assemblies. Equally, everything in an assembly gets deployedwe don't get to pick and choose.

Due to the various physical configurations we want to support, we know that we have several deployment requirements. The server-side DataPortal , for instance, needs to have the option of being installed on a client or on an application server. The BusinessBase class needs to reside anywhere that business objects will be running typically on both client and application server. The ServicedDataPortal runs in Enterprise Services, and can only be deployed on machines where COM+ exists (Windows 2000 or higher).

Note 

I understand that there are some hacks you can use to get Enterprise Services code to run in MTS under Windows NT 4.0. This isn't supported by Microsoft, and may not work with future versions of the .NET Framework, so if you choose to pursue such a route you're on your own. I certainly don't recommend such a course of action.

Table 2-1 breaks this down systematically by deployment requirements.

Table 2-1: Deployment Requirements of the CSLA .NET Assemblies

Deployment Details	Class	Assembly
Client or server	Server-side DataPortal	CSLA.Server.DataPortal
Enterprise Services required	Serviced DataPortal	CSLA.Server.ServicedData Portal
Client and server	NotUndoableAttribute; Core.UndoableBase; BusinessBase; BrokenRules; RulesCollection; Rule data type; BusinessCollectionBase; ReadOnlyBase; ReadOnlyCollectionBase; Client-side DataPortal; TransactionalAttribute ; Security.Principal; Security.Identity; NameValueList; SmartDate; SafeSqlDataReader	CSLA
Client and server	Core.BindableBase; Core.BindableCollectionBase	CSLA.Core.BindableBase

Note 

Note that we can include the classes in CSLA.Core.BindableBase directly in CSLA.dll . We've kept them in a separate DLL to retain parity with the VB .NET version of the framework.

Figure 2-31 is a UML component diagram that illustrates these components and their dependencies graphically.

Figure 2-31: UML component diagram showing the CSLA .NET assemblies

As you can see, CSLA.dll depends on all three of the other components. It contains classes that inherit from those in CSLA.Core.BindableBase.dll and that call into the server-side DataPortal components. Additionally, CSLA.Server.ServicedDataPortal.dll depends on CSLA.Server.DataPortal.dll , because our transactional DataPortal class makes use of the nontransactional server-side DataPortal class.

In Chapter 4, we'll implement the CSLA and CSLA.Core.BindableBase assemblies. In Chapter 5, we'll implement the CSLA.Server.DataPortal and CSLA.Server.ServicedDataPortal assemblies, along with a DataPortal web project that will act as the remoting host on our application server.