SingleCall vs Singleton: which should I use?

[Ronald S. Cook]

I'm implementing .NET Remoting on a project. We have about 12 instances of
the application running at one time, 10 in trucks out in a wireless
enviroment (trucks do not leave the yard.. they are feeding cattle), and 2+
on office PCs inside. The app makes calls like, give me all the data on the
pen I'm about to feed.

While I've seen the list of differences between SingleCall and Singleton,
I'm not sure which to employ.

Can anyone offer some guidance?

Thanks,
Ron

 

[Tom Shelton]

I'm implementing .NET Remoting on a project. We have about 12 instances of
the application running at one time, 10 in trucks out in a wireless
enviroment (trucks do not leave the yard.. they are feeding cattle), and 2+
on office PCs inside. The app makes calls like, give me all the data on the
pen I'm about to feed.

While I've seen the list of differences between SingleCall and Singleton,
I'm not sure which to employ.

Can anyone offer some guidance?

Thanks,
Ron

SingleCall. They are stateless, and therefore can scale better.

 

[Nicholas Paldino [.NET/C# MVP]]

In this case, it might not really matter. If the operations are
stateless, then using a singleton or single call wont really matter.

If the remoting operations are truly stateless, then yes, single call is
better (it doesn't necessarily mean it will scale better) as you will be
able to design your classes as operations, which will help with the design.

If you have any need to retain information between calls, you might
consider a singleton, as you will be able to store state in the singleton.

In the end, it depends on your design.

 

[Tom Shelton]

In this case, it might not really matter. If the operations are
stateless, then using a singleton or single call wont really matter.

If the remoting operations are truly stateless, then yes, single call is
better (it doesn't necessarily mean it will scale better) as you will be
able to design your classes as operations, which will help with the design.

If you have any need to retain information between calls, you might
consider a singleton, as you will be able to store state in the singleton.

In the end, it depends on your design.

Well, here is Ingo Rammer's article on the subject:

http://www.thinktecture.com/Resources/ArchitectureBriefings/RemotingBestPractices.pdf

First rule for reliable and scalable remoting applications (when
calling accross machines):

* Use only server-activated objects configured as SingleCall

Singleton's can be scalable, but they have to be designed carefully.
That's why I suggested SingleCall.

 

[Nicholas Paldino [.NET/C# MVP]]

That's the thing. As a general guideline, yes, I agree, single call is
better. But it's not a hard and fast rule, and it's more important to
understand the ^why^ behind single call than to just know that one should
use it. Once that happens, one can truly make the best choice for them.