[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Remoting Objects: style question

Bob Rundle

7/8/2004 3:32:00 PM

I have a style question wrt Remoting Objects.

I'm trying to avoid putting all my remoting objects in a class library to be
built into both client and server. I'm using C# exclusively.

Two ideas:

1. I have a class library of base class remoting objects. The server
uses class derived from these base classes. The client links in the
baseclasses and accesses derived class functionality through base class
methods.

2. I create interfaces for all the remoting objects and build a class
library from the interfaces which is then referenced by both client and
server.

Advise or comments?

Regards,
Bob Rundle
18 Answers

Ken Kolda

7/8/2004 4:00:00 PM

0

Method #2 is a widely used and widely recommended method for doing remoting.
I don''t see a point to method #1 unless you plan to create derived classes
in your client application as well.

Ken


"Bob Rundle" <rundle@rundle.com> wrote in message
news:uSeUtCQZEHA.4092@TK2MSFTNGP11.phx.gbl...
> I have a style question wrt Remoting Objects.
>
> I''m trying to avoid putting all my remoting objects in a class library to
be
> built into both client and server. I''m using C# exclusively.
>
> Two ideas:
>
> 1. I have a class library of base class remoting objects. The server
> uses class derived from these base classes. The client links in the
> baseclasses and accesses derived class functionality through base class
> methods.
>
> 2. I create interfaces for all the remoting objects and build a class
> library from the interfaces which is then referenced by both client and
> server.
>
> Advise or comments?
>
> Regards,
> Bob Rundle
>
>

Sunny

7/8/2004 4:35:00 PM

0

I preffer the interface approach, while Allen likes the abstract
classes. I can not go deep in any pros and cons on both approaches.
Maybe the bigger pros in the abstract class approach is that Allen has
very good article about it :)

Sunny

P.S. here is the link to Allen''s abstract class article:
http://www.glacialcomponents.com/ArticleDe...
articleID=RemoteObject

In article <uSeUtCQZEHA.4092@TK2MSFTNGP11.phx.gbl>, rundle@rundle.com
says...
> I have a style question wrt Remoting Objects.
>
> I''m trying to avoid putting all my remoting objects in a class library to be
> built into both client and server. I''m using C# exclusively.
>
> Two ideas:
>
> 1. I have a class library of base class remoting objects. The server
> uses class derived from these base classes. The client links in the
> baseclasses and accesses derived class functionality through base class
> methods.
>
> 2. I create interfaces for all the remoting objects and build a class
> library from the interfaces which is then referenced by both client and
> server.
>
> Advise or comments?
>
> Regards,
> Bob Rundle
>
>
>

Allen Anderson

7/8/2004 5:03:00 PM

0

haha, thanks Sunny. I personally prefer the abstract class approach
but Sunny''s preference for interfaces has a lot of upside also. I
think one or either is fine depending on what exactly you want out of
it.


On Thu, 8 Jul 2004 11:34:37 -0500, Sunny <sunny@newsgroups.nospam>
wrote:

>I preffer the interface approach, while Allen likes the abstract
>classes. I can not go deep in any pros and cons on both approaches.
>Maybe the bigger pros in the abstract class approach is that Allen has
>very good article about it :)
>
>Sunny
>
>P.S. here is the link to Allen''s abstract class article:
>http://www.glacialcomponents.com/ArticleDe...
>articleID=RemoteObject
>
>In article <uSeUtCQZEHA.4092@TK2MSFTNGP11.phx.gbl>, rundle@rundle.com
>says...
>> I have a style question wrt Remoting Objects.
>>
>> I''m trying to avoid putting all my remoting objects in a class library to be
>> built into both client and server. I''m using C# exclusively.
>>
>> Two ideas:
>>
>> 1. I have a class library of base class remoting objects. The server
>> uses class derived from these base classes. The client links in the
>> baseclasses and accesses derived class functionality through base class
>> methods.
>>
>> 2. I create interfaces for all the remoting objects and build a class
>> library from the interfaces which is then referenced by both client and
>> server.
>>
>> Advise or comments?
>>
>> Regards,
>> Bob Rundle
>>
>>
>>

Sunny

7/8/2004 6:44:00 PM

0

Actualy, my preference is only linguistic based. Interface is something
(in general, not in C# terms) to which you connect, or with which you
control something.

While abstract class is a base, on which you upgrade ...

And ... I can easily add another interface (only for lets say internal
use) to my remoted object and add the internal (administrative, etc.)
functionality. And this interface will not be distributed to the
clients. While with abstract class you can do the same (add an
interface), you are starting to mix the technologies. 2c :)

Sunny


In article <dgvqe01901npu2klsf5qn2tove239hqnmo@4ax.com>,
allen@sparkysystems.com says...
> haha, thanks Sunny. I personally prefer the abstract class approach
> but Sunny''s preference for interfaces has a lot of upside also. I
> think one or either is fine depending on what exactly you want out of
> it.
>
>
> On Thu, 8 Jul 2004 11:34:37 -0500, Sunny <sunny@newsgroups.nospam>
> wrote:
>
> >I preffer the interface approach, while Allen likes the abstract
> >classes. I can not go deep in any pros and cons on both approaches.
> >Maybe the bigger pros in the abstract class approach is that Allen has
> >very good article about it :)
> >
> >Sunny
> >
> >P.S. here is the link to Allen''s abstract class article:
> >http://www.glacialcomponents.com/ArticleDe...
> >articleID=RemoteObject
> >
> >In article <uSeUtCQZEHA.4092@TK2MSFTNGP11.phx.gbl>, rundle@rundle.com
> >says...
> >> I have a style question wrt Remoting Objects.
> >>
> >> I''m trying to avoid putting all my remoting objects in a class library to be
> >> built into both client and server. I''m using C# exclusively.
> >>
> >> Two ideas:
> >>
> >> 1. I have a class library of base class remoting objects. The server
> >> uses class derived from these base classes. The client links in the
> >> baseclasses and accesses derived class functionality through base class
> >> methods.
> >>
> >> 2. I create interfaces for all the remoting objects and build a class
> >> library from the interfaces which is then referenced by both client and
> >> server.
> >>
> >> Advise or comments?
> >>
> >> Regards,
> >> Bob Rundle
> >>
> >>
> >>
>
>

Henrik de Jong

7/9/2004 7:41:00 AM

0

What I know is that one of the disadvantage of using interface is that you
can''t pass interface-objects as parameters in methods from remoting-objects
because the interface cannot be casted back to the MarshalByRefObject.

So it depends a little of what you want to do.

kinds regards,
Henrik


"Sunny" <sunny@newsgroups.nospam> schreef in bericht
news:uNpB3lQZEHA.2216@TK2MSFTNGP10.phx.gbl...
> I preffer the interface approach, while Allen likes the abstract
> classes. I can not go deep in any pros and cons on both approaches.
> Maybe the bigger pros in the abstract class approach is that Allen has
> very good article about it :)
>
> Sunny
>
> P.S. here is the link to Allen''s abstract class article:
> http://www.glacialcomponents.com/ArticleDe...
> articleID=RemoteObject
>
> In article <uSeUtCQZEHA.4092@TK2MSFTNGP11.phx.gbl>, rundle@rundle.com
> says...
> > I have a style question wrt Remoting Objects.
> >
> > I''m trying to avoid putting all my remoting objects in a class library
to be
> > built into both client and server. I''m using C# exclusively.
> >
> > Two ideas:
> >
> > 1. I have a class library of base class remoting objects. The server
> > uses class derived from these base classes. The client links in the
> > baseclasses and accesses derived class functionality through base class
> > methods.
> >
> > 2. I create interfaces for all the remoting objects and build a class
> > library from the interfaces which is then referenced by both client and
> > server.
> >
> > Advise or comments?
> >
> > Regards,
> > Bob Rundle
> >
> >
> >

Sunny

7/9/2004 2:27:00 PM

0

That''s true. I need to use (MBR) casting, but it does not brake
anything.

Sunny


In article <ezBYWjYZEHA.1152@TK2MSFTNGP09.phx.gbl>, nn@nnnnnn.nl says...
> What I know is that one of the disadvantage of using interface is that you
> can''t pass interface-objects as parameters in methods from remoting-objects
> because the interface cannot be casted back to the MarshalByRefObject.
>
> So it depends a little of what you want to do.
>
> kinds regards,
> Henrik
>
>
> "Sunny" <sunny@newsgroups.nospam> schreef in bericht
> news:uNpB3lQZEHA.2216@TK2MSFTNGP10.phx.gbl...
> > I preffer the interface approach, while Allen likes the abstract
> > classes. I can not go deep in any pros and cons on both approaches.
> > Maybe the bigger pros in the abstract class approach is that Allen has
> > very good article about it :)
> >
> > Sunny
> >
> > P.S. here is the link to Allen''s abstract class article:
> > http://www.glacialcomponents.com/ArticleDe...
> > articleID=RemoteObject
> >
> > In article <uSeUtCQZEHA.4092@TK2MSFTNGP11.phx.gbl>, rundle@rundle.com
> > says...
> > > I have a style question wrt Remoting Objects.
> > >
> > > I''m trying to avoid putting all my remoting objects in a class library
> to be
> > > built into both client and server. I''m using C# exclusively.
> > >
> > > Two ideas:
> > >
> > > 1. I have a class library of base class remoting objects. The server
> > > uses class derived from these base classes. The client links in the
> > > baseclasses and accesses derived class functionality through base class
> > > methods.
> > >
> > > 2. I create interfaces for all the remoting objects and build a class
> > > library from the interfaces which is then referenced by both client and
> > > server.
> > >
> > > Advise or comments?
> > >
> > > Regards,
> > > Bob Rundle
> > >
> > >
> > >
>
>
>

Bob Rundle

7/11/2004 5:25:00 PM

0

I''m going to go the interface route. It seems that this is exactly what
interfaces were made for. I also want to make the interfaces COM visible
and so I think interfaces will be superior in this regard to abstract
classes. Or am I wrong about this?

Bob Rundle

"Sunny" <sunny@newsgroups.nospam> wrote in message
news:ORqdLuRZEHA.384@TK2MSFTNGP10.phx.gbl...
> Actualy, my preference is only linguistic based. Interface is something
> (in general, not in C# terms) to which you connect, or with which you
> control something.
>
> While abstract class is a base, on which you upgrade ...
>
> And ... I can easily add another interface (only for lets say internal
> use) to my remoted object and add the internal (administrative, etc.)
> functionality. And this interface will not be distributed to the
> clients. While with abstract class you can do the same (add an
> interface), you are starting to mix the technologies. 2c :)
>
> Sunny
>
>
> In article <dgvqe01901npu2klsf5qn2tove239hqnmo@4ax.com>,
> allen@sparkysystems.com says...
> > haha, thanks Sunny. I personally prefer the abstract class approach
> > but Sunny''s preference for interfaces has a lot of upside also. I
> > think one or either is fine depending on what exactly you want out of
> > it.
> >
> >
> > On Thu, 8 Jul 2004 11:34:37 -0500, Sunny <sunny@newsgroups.nospam>
> > wrote:
> >
> > >I preffer the interface approach, while Allen likes the abstract
> > >classes. I can not go deep in any pros and cons on both approaches.
> > >Maybe the bigger pros in the abstract class approach is that Allen has
> > >very good article about it :)
> > >
> > >Sunny
> > >
> > >P.S. here is the link to Allen''s abstract class article:
> > >http://www.glacialcomponents.com/ArticleDe...
> > >articleID=RemoteObject
> > >
> > >In article <uSeUtCQZEHA.4092@TK2MSFTNGP11.phx.gbl>, rundle@rundle.com
> > >says...
> > >> I have a style question wrt Remoting Objects.
> > >>
> > >> I''m trying to avoid putting all my remoting objects in a class
library to be
> > >> built into both client and server. I''m using C# exclusively.
> > >>
> > >> Two ideas:
> > >>
> > >> 1. I have a class library of base class remoting objects. The
server
> > >> uses class derived from these base classes. The client links in the
> > >> baseclasses and accesses derived class functionality through base
class
> > >> methods.
> > >>
> > >> 2. I create interfaces for all the remoting objects and build a
class
> > >> library from the interfaces which is then referenced by both client
and
> > >> server.
> > >>
> > >> Advise or comments?
> > >>
> > >> Regards,
> > >> Bob Rundle
> > >>
> > >>
> > >>
> >
> >

Bob Rundle

7/11/2004 7:07:00 PM

0

Sunny,

I seem to have found a serious problem with the interface route.

I have created a number of interfaces and compiled them into an interface
library.

I have discovered that the "is" operator cannot reliably distinguish between
the interfaces that are mashalled through remoting. For example

if(item is IJobQueues)
{
IJobQueues jqs = item as IJobQueues;
jqs.AddJobQueue("asdf");
}

will throw an exception in the AddJobQueue method if item does not actually
implement the IJobQueues interface.

However if I implement everything with abstract classes, everything works
fine. The client never gets confused about the type of the object it is
holding.

This appears to be a serious bug in .NET remoting. What am I missing?

Regards,
Bob Rundle


"Sunny" <sunny@newsgroups.nospam> wrote in message
news:uTSi8CcZEHA.2776@TK2MSFTNGP10.phx.gbl...
> That''s true. I need to use (MBR) casting, but it does not brake
> anything.
>
> Sunny
>
>
> In article <ezBYWjYZEHA.1152@TK2MSFTNGP09.phx.gbl>, nn@nnnnnn.nl says...
> > What I know is that one of the disadvantage of using interface is that
you
> > can''t pass interface-objects as parameters in methods from
remoting-objects
> > because the interface cannot be casted back to the MarshalByRefObject.
> >
> > So it depends a little of what you want to do.
> >
> > kinds regards,
> > Henrik
> >
> >
> > "Sunny" <sunny@newsgroups.nospam> schreef in bericht
> > news:uNpB3lQZEHA.2216@TK2MSFTNGP10.phx.gbl...
> > > I preffer the interface approach, while Allen likes the abstract
> > > classes. I can not go deep in any pros and cons on both approaches.
> > > Maybe the bigger pros in the abstract class approach is that Allen has
> > > very good article about it :)
> > >
> > > Sunny
> > >
> > > P.S. here is the link to Allen''s abstract class article:
> > > http://www.glacialcomponents.com/ArticleDe...
> > > articleID=RemoteObject
> > >
> > > In article <uSeUtCQZEHA.4092@TK2MSFTNGP11.phx.gbl>, rundle@rundle.com
> > > says...
> > > > I have a style question wrt Remoting Objects.
> > > >
> > > > I''m trying to avoid putting all my remoting objects in a class
library
> > to be
> > > > built into both client and server. I''m using C# exclusively.
> > > >
> > > > Two ideas:
> > > >
> > > > 1. I have a class library of base class remoting objects. The
server
> > > > uses class derived from these base classes. The client links in the
> > > > baseclasses and accesses derived class functionality through base
class
> > > > methods.
> > > >
> > > > 2. I create interfaces for all the remoting objects and build a
class
> > > > library from the interfaces which is then referenced by both client
and
> > > > server.
> > > >
> > > > Advise or comments?
> > > >
> > > > Regards,
> > > > Bob Rundle
> > > >
> > > >
> > > >
> >
> >
> >

Allen Anderson

7/12/2004 4:44:00 PM

0

if you read my previous posts, you''ll see this is exactly why I use
abstract classes instead of interfaces.

Cheers,
Allen Anderson
http://www.glacialcomp...
mailto: allen@put my website base here.com

On Sun, 11 Jul 2004 14:07:17 -0500, "Bob Rundle" <rundle@rundle.com>
wrote:

>Sunny,
>
>I seem to have found a serious problem with the interface route.
>
>I have created a number of interfaces and compiled them into an interface
>library.
>
>I have discovered that the "is" operator cannot reliably distinguish between
>the interfaces that are mashalled through remoting. For example
>
>if(item is IJobQueues)
>{
> IJobQueues jqs = item as IJobQueues;
> jqs.AddJobQueue("asdf");
>}
>
>will throw an exception in the AddJobQueue method if item does not actually
>implement the IJobQueues interface.
>
>However if I implement everything with abstract classes, everything works
>fine. The client never gets confused about the type of the object it is
>holding.
>
>This appears to be a serious bug in .NET remoting. What am I missing?
>
>Regards,
>Bob Rundle
>
>
>"Sunny" <sunny@newsgroups.nospam> wrote in message
>news:uTSi8CcZEHA.2776@TK2MSFTNGP10.phx.gbl...
>> That''s true. I need to use (MBR) casting, but it does not brake
>> anything.
>>
>> Sunny
>>
>>
>> In article <ezBYWjYZEHA.1152@TK2MSFTNGP09.phx.gbl>, nn@nnnnnn.nl says...
>> > What I know is that one of the disadvantage of using interface is that
>you
>> > can''t pass interface-objects as parameters in methods from
>remoting-objects
>> > because the interface cannot be casted back to the MarshalByRefObject.
>> >
>> > So it depends a little of what you want to do.
>> >
>> > kinds regards,
>> > Henrik
>> >
>> >
>> > "Sunny" <sunny@newsgroups.nospam> schreef in bericht
>> > news:uNpB3lQZEHA.2216@TK2MSFTNGP10.phx.gbl...
>> > > I preffer the interface approach, while Allen likes the abstract
>> > > classes. I can not go deep in any pros and cons on both approaches.
>> > > Maybe the bigger pros in the abstract class approach is that Allen has
>> > > very good article about it :)
>> > >
>> > > Sunny
>> > >
>> > > P.S. here is the link to Allen''s abstract class article:
>> > > http://www.glacialcomp.../ArticleDetail.aspx?
>> > > articleID=RemoteObject
>> > >
>> > > In article <uSeUtCQZEHA.4092@TK2MSFTNGP11.phx.gbl>, rundle@rundle.com
>> > > says...
>> > > > I have a style question wrt Remoting Objects.
>> > > >
>> > > > I''m trying to avoid putting all my remoting objects in a class
>library
>> > to be
>> > > > built into both client and server. I''m using C# exclusively.
>> > > >
>> > > > Two ideas:
>> > > >
>> > > > 1. I have a class library of base class remoting objects. The
>server
>> > > > uses class derived from these base classes. The client links in the
>> > > > baseclasses and accesses derived class functionality through base
>class
>> > > > methods.
>> > > >
>> > > > 2. I create interfaces for all the remoting objects and build a
>class
>> > > > library from the interfaces which is then referenced by both client
>and
>> > > > server.
>> > > >
>> > > > Advise or comments?
>> > > >
>> > > > Regards,
>> > > > Bob Rundle
>> > > >
>> > > >
>> > > >
>> >
>> >
>> >
>

Sunny

7/12/2004 5:58:00 PM

0

I have never tried it the way you do it. There was some articles about
what you are doing, and the conclusion was, that there is no need of
combo is/as, because it makes 2 casts.

Try "as" and check for null. It works for me.

IJobQueues jqs = item as IJobQueues;
if (jgs != null)
jqs.AddJobQueue("asdf");

Sunny

In article <ORy8Gp3ZEHA.2216@TK2MSFTNGP10.phx.gbl>, rundle@rundle.com
says...
> Sunny,
>
> I seem to have found a serious problem with the interface route.
>
> I have created a number of interfaces and compiled them into an interface
> library.
>
> I have discovered that the "is" operator cannot reliably distinguish between
> the interfaces that are mashalled through remoting. For example
>
> if(item is IJobQueues)
> {
> IJobQueues jqs = item as IJobQueues;
> jqs.AddJobQueue("asdf");
> }
>
> will throw an exception in the AddJobQueue method if item does not actually
> implement the IJobQueues interface.
>
> However if I implement everything with abstract classes, everything works
> fine. The client never gets confused about the type of the object it is
> holding.
>
> This appears to be a serious bug in .NET remoting. What am I missing?
>
> Regards,
> Bob Rundle
>
>
> "Sunny" <sunny@newsgroups.nospam> wrote in message
> news:uTSi8CcZEHA.2776@TK2MSFTNGP10.phx.gbl...
> > That''s true. I need to use (MBR) casting, but it does not brake
> > anything.
> >
> > Sunny
> >
> >
> > In article <ezBYWjYZEHA.1152@TK2MSFTNGP09.phx.gbl>, nn@nnnnnn.nl says...
> > > What I know is that one of the disadvantage of using interface is that
> you
> > > can''t pass interface-objects as parameters in methods from
> remoting-objects
> > > because the interface cannot be casted back to the MarshalByRefObject.
> > >
> > > So it depends a little of what you want to do.
> > >
> > > kinds regards,
> > > Henrik
> > >
> > >
> > > "Sunny" <sunny@newsgroups.nospam> schreef in bericht
> > > news:uNpB3lQZEHA.2216@TK2MSFTNGP10.phx.gbl...
> > > > I preffer the interface approach, while Allen likes the abstract
> > > > classes. I can not go deep in any pros and cons on both approaches.
> > > > Maybe the bigger pros in the abstract class approach is that Allen has
> > > > very good article about it :)
> > > >
> > > > Sunny
> > > >
> > > > P.S. here is the link to Allen''s abstract class article:
> > > > http://www.glacialcomponents.com/ArticleDe...
> > > > articleID=RemoteObject
> > > >
> > > > In article <uSeUtCQZEHA.4092@TK2MSFTNGP11.phx.gbl>, rundle@rundle.com
> > > > says...
> > > > > I have a style question wrt Remoting Objects.
> > > > >
> > > > > I''m trying to avoid putting all my remoting objects in a class
> library
> > > to be
> > > > > built into both client and server. I''m using C# exclusively.
> > > > >
> > > > > Two ideas:
> > > > >
> > > > > 1. I have a class library of base class remoting objects. The
> server
> > > > > uses class derived from these base classes. The client links in the
> > > > > baseclasses and accesses derived class functionality through base
> class
> > > > > methods.
> > > > >
> > > > > 2. I create interfaces for all the remoting objects and build a
> class
> > > > > library from the interfaces which is then referenced by both client
> and
> > > > > server.
> > > > >
> > > > > Advise or comments?
> > > > >
> > > > > Regards,
> > > > > Bob Rundle
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>