Tip 11: The Baker's Spotlight: Applying Generics to Simplify Remoting Interfaces
The very simple example contained one interface and one method. Let's think about a real-world application for a moment. You could have a dozen modules, each containing a method to retrieve data for a primary key. That might mean GetProduct
, etc. And then you might have other categories of functions for the various modules. Does that mean you're potentially facing a proliferation of interfaces?
In Visual Studio 2005, the answer is: not necessarily. Applying Carl Franklin's observation that generics can simplify classes that differ by an internal type, you could define a generic interface that receives a single primary key integer (it could be an account key or a product key), and returns a dataset (it could be account results or product results).
public interface IRemoteGenericResultSet<T>
DataSet GetResults(int nID);
Note the syntax: the
placeholder indicates that this is a generic. When you refer to the actual Type, you will represent it in the same way. The following code demonstrates a reference to an object that implements this generic interface:
string cServer = "tcp://localhost:8228";
object oRemoteObject =
cServer + "/GetCustomers");
IRemoteGenericResultSet<DataSet> oCustomer =
Note that the calling procedure doesn't contain any type references to a specific module. There is the literal for the name of the back-end object, which you could easily place into a string or property.
This is one of many ways generics can simplify programming. I'll devote a future Baker's Dozen article to generics in detail.
Tip 12: Creating a Remoting Object Factory
Another way you can simplify remoting is to abstract the details of remoting to a separate class. Listing 1
contains the code for a remoting object factory. If an application needs to access many remote objects, you can instantiate this factory, set the properties for the port, server, interface, and type reference to the desired back-end object, and then case the return value to the interface you need.
Tip 13: Using the remoting object factory
Here is a simple example of using the factory:
RemotingFactory oFactory = new RemotingFactory();
oFactory.nTCPPort = 8228;
oFactory.cTcpServer = "tcp://localhost";
oFactory.cRemoteObjectName = "CustomerBzObject";
oFactory.tInterface = typeof(ICustomer);
DataSet DsTemp= oRemoteCustomer.GetCustomer(111);
Note that no actual remoting code exists in the snippet above, other than setting address properties that are merely for demonstration. The key point here is that the remoting object factory handles all the complexities of remoting.
The Baker's Dozen Commentary
I've learned a great deal over the last year about developers' reactions towards remoting. Many developers avoid remoting because of perceived complexities. I set out to demonstrate that although a few additional steps are necessary, you can abstract out those steps from the rest of your application. In the very beginning, I found remoting to be a bit complex but became comfortable after a bit of study. I now use it whenever possible.
I've also been pleasantly surprised at the number of developers who use remoting. And although some have adopted a position of waiting for Indigo and other coming technologies, many developers need to know how to solve application issues now. Incidentally, that's one of the goals of the Baker's Dozen: to demonstrate how to use technology that exists today.
Hopefully this step-by-step approach served to explain remoting, as well as demonstrated the benefits of strongly typed development. Even with the new capabilities of future Microsoft development technologies (Indigo), many will continue to use remoting, at least for the near-term.
Article Source Code
You can find the entire source code for this article on my Web site
. For additional information, check out my blog