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 ( WCF: Is there a way to return an object that is able to execute on the server? ), 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

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.