C# Remoting classes organization

Question

Hi, I'm developing a Remoting classes library so that I can keep database interaction and business object on the server and not on clients.

I'd like to be able to return my own objects to the clients so that they can interact with them through the server itself.

For example (semi-pseudocode):

Server

class Database { ... }
class Utility
{
  public User getUser(username)
  {
     return new User(username);
  }
}
class User
{
  public string[] getPerms()
  {
    return Database.query("select * from permission where user = " + this.username);
  }
}

Client

Utility utility = (Utility)getRemotingClass("Utility");
User user = Utility.getUser("admin");
string[] perms = user.getPerms();

How can I organize my classes/namespaces? I'm particularly wondering about class references and scalability of my system.

Any kind of criticism/suggestion is really appreciated.

Answer 1

I don't mean to beat a drum, but you might want to look into WCF. Remoting is very chatty and the real support for maintaining clean interfaces by .Net is being done through WCF and message passing, as opposed to full object state management through remoting.

What it sounds like you are doing is developing a middle tier for management of the database connections. Just make sure you don't end up redeveloping the interface to SQL server.

Answer 2

I tend to put all the 'shared' (Data Transfer Object) classes in a separate DLL which both the server and the client reference (you could put them in the same DLL as the server classes if you're going to distribute it with the client code anyway).

By putting them in a separate assembly, you reinforce the de-coupling of the DTOs and the underlying technology used to remotely transfer them. This means that if you end up rewriting the remote call technology, you won't have to touch the DTOs and can just re-use the assembly.

Don't forget to mark the DTOs as with the [Serailizable] attribute so they can be transported between the client and the server.

Herbie