How do I return an object that is able to execute on the server?

Question

Coming from a Java background, this is the way I'm thinking:

The server provides an object to the client. This object should be able to execute on the server.

Server:

private string _S = "A";

public interface IFoo { void Bar(); }

private class Foo : IFoo {
    void Bar() { _S = "B";}
}

public IFoo GetFoo() { return new Foo(); }

Client:

IFoo foo = serverChannel.GetFoo();
foo.Bar();

Remoting is legacy (everyone keeps pointing to WCF instead) and WCF does not support this at all basically ( http://stackoverflow.com/questions/2431510 ), so how should I implement this kind of behavior? Using 3rd party components is possible iff required.

I searched on SO but found no similar question. If this has indeed been answered before, just let me know and I'll delete.

Answer 1

WCF is indeed message based, Remoting still works.... the real question is: why don't you want to work message based?

Answer 2

If you want type sharing in WCF - like what you described and was in remoting, sharing (interface) declarations in common assemblies on the server and client - you can do it by using the NetDataContractSerializer. It helped others as well.

It's use is discouraged - just like remoting -, contract based messaging seems to be all the rage right now.

I should add that with a proper design you will still end up with a contract/message based application even with .Net Remoting. Your shared interfaces will become the operation contracts, while your shared data class definitions will describe the data contracts/messages you pass.

Answer 3

I recommend not trying to "remote" objects. It's a dangerous idea.

1. You don't have local control over remote state. You never do.
2. Trying to reason about what is the "true" state and what isn't gets very complicated very quickly.
3. Thinking in terms of messages will likely result in a design which is more "correct" from a networking viewpoint - that is, a design which correctly allocates responsibilities and does not make inappropriate assumptions.
4. A message-based network app will almost certainly be more robust.
5. A remoting-based app will typically allow for faster initial development, but result in a ton of extra time in the long run dealing with edge conditions, etc.

Really, don't do it. Remote objects are just kind of bad. At a core level, networking is about transmitting data. Having your program work with the same model will make your life much, much easier in the long run.