MBR IT/.NET 247 : Interface based serialization on microsoft.public.dotnet.framework.remoting

Interface based serialization

Messages

Related Types

This message was discovered on microsoft.public.dotnet.framework.remoting.

Noel Watson

I am attempting to get the example posted on csharphelp to work
http://www.csharphelp.com/archives/archive191.html

The example executes fine, but when checking whether the call

IResume aResume = resService.GetResume();

is passed copied locally to the machine (ByVal), I find that it has
been passed byRef. My check for this is adding a property returning
Environment.MachineName - calling this new property returns the name
of the remote machine.
My understanding is that adding the [Serializable] attribute to the
class Resume would make it serializable. However, it would appear that
adding MarshalByRefObject overrides this and makes it ByRef. Removing
MarshalByRefObject cause the application to fall over as it cannot
find the server assembly - something that can be solved by adding a
reference in Client - obviously this removes the benefits of
Interfaces.

Thanks for reading

Noel

Reply to this message...

Ken Kolda

You are correct that if the class derives from MarshalByRefObject then it
will be remoted by ref (even if also marked as serializable). You're also
right that if the class is only serializable then the client must have the
full class implementation available to it. Those are the rules, so you need
to figure out how to build your app to work within them.

What I usually do is define a set of data classes (e.g. a InventoryItem or a
Resume object) -- these are purely data classes which are serializable and
are implemented in the same assembly as my remoting interfaces. Essentially,
they are part of the "interface" between my clients and my server.

My MBRO classes are essential business logic classes, e.g. for
getting/saving the data objects, for performing various operations, etc.
These business processes aren't needed on the client (and, really, the
server should control them for security/consistency purposes), so only the
interfaces are exposed to them.

Ken

"Noel Watson" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

Noel Watson

Thanks for the response Ken,

One thing is still puzzling me. Are you not taking away some of the
advantages of interface based remoting (not deploying server code to
the client) by having to place your serializable objects on the
client's machine. I've read the two main books on Remoting (Ingo's and
MSPress) and I don't believe either of them mentioned this
requirement.

Noel

Reply to this message...

Ken Kolda

I don't think it takes away from it -- in fact, it makes perfect sense to
me. From a technical point of view, it's clear that if the client has its
own local copy of the object then it must also have the implementation code
for that object. Otherwise, when you call a property or method on the
object, how would the client know what to do? For MBRO objects, it doesn't
need the implementation since the call is forwarded to the server -- all it
needs is to know the property arguments and return value. But for
marshal-by-value objects, complete knowledge of the object is required.

As I mentioned before, from a logical point of view I think of serializable
types as part of the client/server interface. They provide a means for
passing data objects back and forth. Business logic classes should generally
by MBR. Because they're part of the "interface", having both client and
server know them is completely reasonable/expected.

Ken

"Noel Watson" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

	System.Environment
	System.MarshalByRefObject

MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

	Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
	Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com