Remoting a collection class?

  • Thread starter Thread starter Microsoft
  • Start date Start date
M

Microsoft

I want to create a collection class (List or SortedList, etc) that is
remotable (inherits MarshalByRefObject). Because C# doesn't support
multiple class inheritance I can't just do this:

public class Groups : List, MarshalByRefObject

I know I can implement all of the collection interfaces myself but what a
hassle. Is there a simpler way?
 
I want to create a collection class (List or SortedList, etc) that is
remotable (inherits MarshalByRefObject). Because C# doesn't support
multiple class inheritance I can't just do this:

public class Groups : List, MarshalByRefObject

I know I can implement all of the collection interfaces myself but what a
hassle. Is there a simpler way?
Click to expand...

I don't think that you can but that would be a very bad design idea IMHO.
Don't forget that a MarshalByRefObject stays on the server and that client
applications only get a proxy object to the actual object. Each and every
function and property call on a MarshalByRefObject via .NET Remoting
involves at least 1 network round trip which takes a lot of time. A
collection being generally used in loops (to loop through all their values)
or in general accessed very often and to retrieve only a very small amount
of data, having your collection MarshalByRefObject would almost certainly
kill the performance of your application.

Consider either sending a serialized copy of your collection so that each
client would get their own local copy or, if the collection must remain on
the server, provide remote methods to access its data (and try to always
return as much data as you can instead of only returning small chunks of
data so that clients do not have to call the method too often).
 
Return the list to client MBV.

--
William Stacey [MVP]

|I want to create a collection class (List or SortedList, etc) that is
| remotable (inherits MarshalByRefObject). Because C# doesn't support
| multiple class inheritance I can't just do this:
|
| public class Groups : List, MarshalByRefObject
|
| I know I can implement all of the collection interfaces myself but what a
| hassle. Is there a simpler way?
|
|
 
Performance is not an issue. Both client and server are on the same box.
Remoting is only being used for IPC.
 
What's dumb is that to implement such a remotable collection is just a
matter of implementing the required interfaces and inheriting
MarshalByRefObject. So why didn't Microsoft just provide remotable
collections?
 
What's dumb is that to implement such a remotable collection is just a
matter of implementing the required interfaces and inheriting
MarshalByRefObject. So why didn't Microsoft just provide remotable
collections?
Click to expand...

I suppose that it's simply to avoid people from mistakenly remoting a
collection by reference, which, in the vast majority of cases, is a very
bad idea. If collections were MarshalByRefObject, then whenever they would
be used as an argument or return value of a remote method (which is a very
common scenario), they would by default be passed as MarshalByRefObject.
Many developers without a good experience of .NET Remoting and without very
good testing practices may not notice the problem straight away since
testing during development time is usually done either locally or within a
fast LAN where the overhead of remoting a collection by reference might go
unoticed. But when they would deploy their app in the real world, BANG, the
whole thing would collapse. Not to mention that if later the application
has to be modified, the maintainer might not notice this kind of subtelty
if there are not appropriate comments in the code. If there is really a
need to access a remote collection by reference, then writing a simple
MarshalByRefObject wrapper class that provides the required functionnality
is straightforward and would avoid this kind of problems.

Even when designing a .NET Remoting system where both the server and client
application are to run on the same computer, i believe that designing the
system so that it could also be used if both applications are remote is
often (not always of course) a good idea. It often doesn't really requires
much more work and if later the need arises to run both app on 2 separate
computers, it would just be a matter of changing a few lines of code or a
configuration file and would not mean to have to redesign the whole thing.
 
Back
Top