Object-Oriented Programming with Visual Basic .NET

9.5. Designing for Remoting

Designing an object that lives in distributed environments almost runs counter to traditional OOP, in which public interfaces are kept lean and mean. Here are some general guidelines for remotable objects:

• Avoid "chatty" objects. These objects contain numerous properties that generate unnecessary traffic over the wire. Remember, each time a property is set, a round-trip on the network occurs.

• Make "chunky" calls. This means passing as much data as possible when making a method call.

• The method on a remote object should be Herculean. Normally, a method performs one specific task. In a remoting situation, a method should perform as many tasks as possible before returning.

• Return as much data as possible from a remote method. When you can, try to use structures containing only value types (but only if you know that boxing and unboxing will be kept to a minimum once the data is across).

The "GC allocations and collections" item in the Performance Monitor tells you how much boxing and unboxing is occurring.

Here are some general guidelines for the various activation models:

• Singletons are ideal for providing and maintaining data that is static or updated very infrequently. The services provided by a Singleton are not specific to any client.

• SingleCall objects are stateless and best used in high-traffic situations (for reasons of scalability) when ...