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?

Re: Remoting a collection class? by Mehdi

Mehdi
Fri Mar 24 04:33:42 CST 2006

On Thu, 23 Mar 2006 19:42:17 -0500, Microsoft wrote:

> 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 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).

Re: Remoting a collection class? by William

William
Fri Mar 24 07:21:12 CST 2006

Return the list to client MBV.

--
William Stacey [MVP]

"Microsoft" <none@nowhere.com> wrote in message
news:eC09NwtTGHA.4080@TK2MSFTNGP10.phx.gbl...
|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?
|
|



Re: Remoting a collection class? by Dave

Dave
Fri Mar 24 22:09:00 CST 2006

Performance is not an issue. Both client and server are on the same box.
Remoting is only being used for IPC.


"Mehdi" <vioccc@REMOVEME.gmail.com> wrote in message
news:14a9ncrmhm7hy$.1c4u4gxvqekuh.dlg@40tude.net...
> On Thu, 23 Mar 2006 19:42:17 -0500, Microsoft wrote:
>
>> 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 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).



Re: Remoting a collection class? by Dave

Dave
Sat Mar 25 16:27:52 CST 2006

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?



Re: Remoting a collection class? by Mehdi

Mehdi
Tue Mar 28 05:13:31 CST 2006

On Sat, 25 Mar 2006 17:27:52 -0500, Dave wrote:

> 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?

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.