|The only item that I would say you should make an adjustment to is the ISerializable implementation. The reason I say so is that you have to implement your own serializer/deserializer!!!
Just add the [Serializable] attribute. The process of 'going remote' goes through several SinkProviders including the BinarySerializer. So implementing the ISerializable interface just creates redundancy.
Now ---> once you get everything set to run with SAO instead of CAO, all you need to do is the following:
1) Get your app finished and working so your server objects
2) Set up a stress test if possible
3) Now you can compare the impacts to your app on whether or
not you should be Singleton or SingleCall.
IMHO -- this ends being based on application process and design rather than just a cookie-cutter decision. For my app, I found that having the objects there was great and the Singletons will eventually be flushed if no activity occurs, but remain when activity is high.
For me, I was initializing collections of objects remotely and passing single instances back to the caller. Great setup for a Singleton. If I did not need the populated collections, I probably could get away with the SingleCall.
Of all the senses I could possibly lose,
It is most often the one called 'common' that gets lost.