Tip 2: Understanding the Different Options in Remoting
There are two flavors of remoting: TCP and HTTP. That gives us a grand total of three different options for distributed computing when you add .NET Web services into the mix. Note that they're not mutually exclusive: an application might use Web services between the client and application tiers and remoting inside the application tiers.
So let's take a moment and look at the three, and common reasons that they're used:
- ASP.NET Web services are the way to go when you must support SOAP over HTTP, and/or you have non-.NET applications accessing the application.
- HTTP remoting is an option for installations that always use .NET for all layers, but also must make use of HTTP. You can set up your remoting components under IIS to use authentication and security features.
- TCP remoting in Visual Studio 2003 was an excellent choice for internal applications that didn't require security. TCP remoting is generally (and in some instances, significantly) the fastest of the three. Visual Studio 2005 also extends TCP remoting by offering security capabilities (see Tip 9). This makes TCP remoting even more attractive for applications beyond internal ones.
Visual Studio 2005 enhances remoting even further by allowing developers to serialize datasets across application boundaries in a binary format (see Tip 7). This eliminates the need to programmatically convert DataSets to or from XML strings, and reduces the size of the dataset when you pass it across physical boundaries.
Tip 3: Building Remoting Interfaces
As stated in Tip 1, the first step is to create an interface. The external class that you wish to access implements this interface. The client piece accesses the external class by means of this interface.
public interface ICustomer
DataSet GetCustomer(int AccountID);
// we could have more, like a
// SaveData method
//void SaveData(DataSet CustomerData);
Note that the interface contains no actual code for GetCustomer
. The only significance is that any class implementing this interface must have a method called GetCustomer
that receives an account ID and returns a DataSet. As you'll see later, that's all the client side needs.
Tip 4: Building the Back-end Remoting Objects
The next step is to build the external business object. In a nutshell, the external class must do three things:
- Implement ICustomer
- Inherit from a .NET system class called MarshalByRefObject, which enables remote code to execute the class on the domain of the external method
- Inherit from a base business object
This immediately presents a challenge: a single class can inherit from one class and one interface, but it cannot inherit from multiple classes. You can resolve this by defining a base business object (BaseBzObject) that inherits from MarshalByRefObject. Then you can define the actual business object (SimpleCustomerBzObject) to inherit from BaseBzObject and implement ICustomer.
|Carl Franklin (DotNetRocks) provides an excellent example of the value of generics-a great way to simplify multiple classes that differ by an internal type.|
This way, SimpleCustomerBzObject still picks up the critical inheritance of MarshalByRefObject from the BaseBzObject.
Here is the code for BaseBzObject:
public class BaseBzObject :
// Base business object methods go here
Here is the code for SimpleCustomerBzObject:
public class CustomerBzObject : BaseBzObject,
public DataSet GetCustomer(int AccountID)
// do something, return a dataset