Proxy to native object conversion

In WCF, if I have a class library that is used on both client and server, is
it possible to automate deserializing directly to the class library's real
types, or must I do manual conversion from the proxy client?

Might it suffice to just give it the [Serializable] attribute, rather than
[DataContract] ?

I already implemented with manual proxy conversion, but I'd like to know
that I don't have to do that again if I don't want to (i.e. if the service
will never be exposed to anyone else's codebase).

I like WCF for easily opening endpoints without plumbing code, but not for
its imposition of contracts, which is great for SOA but can be pointless for
internal IPC.

Jon

If you have the class library at both ends, you can completely forego
the proxy step; you just need to create (at runtime) a proxy for the
interface in question.

I posted more details on this a little while ago - see 23 May 07, "How
to generate proxy class for client?"

Marc

"Marc Gravell" <marc.gravell@gmail.com> wrote in message
news:OD2BYNMrHHA.4984@TK2MSFTNGP03.phx.gbl...
> If you have the class library at both ends, you can completely forego the
> proxy step; you just need to create (at runtime) a proxy for the interface
> in question.
>
> I posted more details on this a little while ago - see 23 May 07, "How to
> generate proxy class for client?"

Thanks. So without the proxy, are you still limited to interfaces for the
data structures going back and forth, or can you still use serializeable
classes? (I'm assuming the latter. Not that using full-blown classes is
good design, but there are exceptions.)

Jon

Actually, interfaces are not generally (ever?) used to describe the
data structures. Data structures must be concrete in order to re-
construct them at the other end, and hence generally involve concrete
classes (or sometimes a list of known concrete types that subclass /
implement a type / interface). For WCF this could be a [DataContract]
class or a [Serializable] class. At a push you might be able to use
some kind of surrogate setup, but almost always: classes.

An interface is, however, typically used (in WCF) to describe the
service contract - the "what can I do?"; specifically one marked
[ServiceContract] with [OperationContract] members. The documentation
suggests that it is technically possible to use this on a class, but
I've never tried it; this feels naturally like an interface. This has
other advantages: you can implement the interface in a variety of
ways, allowing for some very flexible SOA options; for instance, my
business layer simply asks a factory for "something implementing
ISomeContract" - this *could* be a WCF implementation (in a smart-
client or server-to-server scenario), but could equally be a DAL (in a
rich-client or server-to-database scenario). The business layer
doesn't need to know *what* is providing the service - just what is
available.

Marc