Joshua Belden
9/20/2004 7:37:00 PM
Ken, I thank you; you paved a road into my otherwise dead end.
"Ken Kolda" wrote:
> See comments inline below...
>
>
> "Joshua Belden" <JoshuaBelden@discussions.microsoft.com> wrote in message
> news:9D6EE2C7-4C05-440A-B2A0-B8440E5BB25D@microsoft.com...
> > Holy Crap, which means my initial understanding of Remoting is completely
> > backwards. BTW, thanks for getting back to me, I thought with my little
> > triple post circus act, you had left.
> >
> > You're absolutely correct, my intent is to have each client retrieve it's
> > own instance of Widget. My approach is actually to expose a common IWidget
> > interface that the client expects, that way later, modifications to the
> > interworkings of Widget will only have to be updated on the server.
> >
> > Back to the remoting, I have a WidgetManager class that I could expose a
> > GetNewWidget(). But now I'm wondering about it's call mode. I thought that
> > SingleCall would return an instance of the Widget to the client, oh holy
> > crap, now I get it. So if Widget exposed two methods, a calling either one
> > would be a different object.
>
> Correct -- if you expose a server-activated object (SAO) that is SingleCall,
> every invocation of a method/property/etc. accesses a completely new
> instance of the object. In your case, this is definitely not what you want.
>
> >
> > Is my understanding correct then, if my WidgetManager class is exposed as
> > SingleCall and it exposes a GetNewWidget(), I can call that and actually
> get
> > a full instance of the Widget class. Does that mean that methods exposed
> in
> > the Widget class would be run locally, or would they still be run from the
> > server. Some context here, Widget needs to have an Update method, but the
> > actual data transaction needs to happen on the server.
> >
>
> That's right -- your WidgetManager could either be SingleCall or Singleton
> in this case. The implementation of GetNewWidget() would simply be:
>
> public Widget GetNewWidget()
> {
> return new Widget();
> }
>
> As long as your Widget class derived from MarshalByRefObject, the Widget
> will "live" on the server. Thet GetNewWidget() function will just return a
> proxy to the client. If you wanted it passed by value (which it doesn't
> sounds like you do), you would mark the class as Serializable and NOT have
> it derive from MarshalByRefObject.
>
> As for using interfaces to keep the implementation on the server, this is a
> very good idea. In general, a remoting server and client should only share:
>
> * The interfaces for any class which is shared and is MarshalByRef
> * The implementation for any class which is shared and is marshal-by-value
> (i.e. Serializable, non-MarshalByRef).
>
> This provides the maximum amount of isolation between the two sides.
> Generally, your serializable classes should represent data objects with
> minimal business logic. The MBR object should be your business classes so
> the business logic is kept on the server.
>
> Hope all that helps -
> Ken
>
>
> > "Ken Kolda" wrote:
> >
> > > I can't believe this wasn't the first thing I though of, but the problem
> is
> > > that your Widget class is remoted as SingleCall. Thus, the call to get
> the
> > > Name property is made on a different instance than the call to set the
> Name
> > > property.
> > >
> > > Based on what you're doing, it looks like maybe you want your Widget
> class
> > > to be client-activated so that each client gets its own instance of the
> > > class to manipulate (and which isn't SingleCall). If that's the case,
> your
> > > best bet is to add a method to your server called "CreatWidget()" or
> > > something that returns a "new Widget()" object.
> > >
> > > Ken
> > >
> > >
> > > <joshuabelden@hotmail.com> wrote in message
> > > news:ck5uk09h8avmu689305j8loisb28danauj@4ax.com...
> > >
> > >
> > >
>
>
>