Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

The Baker's Dozen: 13 Productivity Tips for Remoting in Visual Studio 2005 : Page 5

Remoting is a powerful technology for implementing distributed applications. Interfaces make it possible to access external code in a strongly-typed manner. Generics in Visual Studio 2005 simplify the process even further.


advertisement
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, GetAccount, GetCostCenter, 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).

using System; using System.Collections.Generic; using System.Text; using System.Data; namespace GenericInterfaces { 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 = Activator.GetObject( typeof(IRemoteGenericResultSet<DataSet>), cServer + "/GetCustomers"); IRemoteGenericResultSet<DataSet> oCustomer = oRemoteObject as IRemoteGenericResultSet<DataSet>; oCustomer.GetResults(111);

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:



using SimpleInterfaces; RemotingFactory oFactory = new RemotingFactory(); oFactory.nTCPPort = 8228; oFactory.cTcpServer = "tcp://localhost"; oFactory.cRemoteObjectName = "CustomerBzObject"; oFactory.tInterface = typeof(ICustomer); ICustomer oRemoteCustomer; oRemoteCustomer = (ICustomer)oFactory.GetRemoteInterfaceObject(); 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.

Closing Thoughts:
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.



Kevin S. Goff is the founder and principal consultant of Common Ground Solutions, a consulting group that provides custom web and desktop software solutions in .NET, Visual FoxPro, SQL Server, and Crystal Reports. Kevin has been building software applications for 17 years. He has received several awards from the U.S. Department of Agriculture for systems automation. He has also received special citations from Fortune 500 companies for solutions that yielded six-figure returns on investment. He has worked in such industries as insurance, accounting, public health, real estate, publishing, advertising, manufacturing, finance, consumer packaged goods, and trade promotion. In addition, Kevin provides many forms of custom training.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap