Remoting/Threading

[danielhamd]

I am somewhat new to the concept of remoting in c#. Here is my
scenario, if anyone could give me some tips I would really appreciate
it:

I have a server program running that updates a database and a binary
file every hour - this process takes approximately 10-15 seconds to
complete. There are going to be 300-400 client machines that will
have a client program running that connect to this server program
every day at random times (such as whenever a user logs in). This
client program calls a function on the server that returns certain
data from it's databases. I want to make sure that while the server
is updating, the client machines will wait at a lock or something
similar from threading until it is finished.

Currently, I have all the server and client calls encapsulated in one
large static class, figuring that making everything static would cause
less collisions. I don't know if this is good design, though. From
reading I get the impression that I should separate them into two
classes, but I'm not exactly clear on the best practice for making
this all work in the context of remoting. Any guidance or suggestions
would be appreciated.

Thanks,
Daniel

 

[John Vottero]

One problem that I see, I think you're going to have to distribute the the
large static class to all the clients when they don't really need it. You
might be better off defining an interface that the static class implements.
Then, the clients just need the interface definition. You'll wind up with a
client exe, an interface dll and a server exe. The only piece that needs to
be on both ends is the interface dll. That also gives you more options when
you upgrade the server. You don't want to get yourself into a situation
where you need to upgrade the server and all of the clients at the same
time.

 

[danielhamd]

That's actually exactly how I have it. There is a common library that
has an interface that the Server implements, which basically just
calls functions from the static class.