Vista - How to avoid exposing own types?

Hi,

I have a Windows Servicing inlcuding a WCF process which accepts
"Jobs". I have created a class named "Job" which has different
properties (FileInfo, String, ... and a generic Queue of another own
definied class named "VideoCut"). The "Job" and "VideoCut" classes are
both defined in a 3rd project and both (the server and client) should
use the classes from the 3rd project and not the via WSDL exposed
"Job" and "VideoCut" classes.

Anyone know how to do this?

Thanks,
Olcay

Yes, use the ChannelFactory class:

ChannelFactory<IServiceInterface> factory = new
ChannelFactory<IServiceInterface>(binding, address);

IServiceInterfacechannel = factory.CreateChannel();



<olcayb@gmail.com> wrote in message
news:1171024142.135965.256670@k78g2000cwa.googlegroups.com...
> Hi,
>
> I have a Windows Servicing inlcuding a WCF process which accepts
> "Jobs". I have created a class named "Job" which has different
> properties (FileInfo, String, ... and a generic Queue of another own
> definied class named "VideoCut"). The "Job" and "VideoCut" classes are
> both defined in a 3rd project and both (the server and client) should
> use the classes from the 3rd project and not the via WSDL exposed
> "Job" and "VideoCut" classes.
>
> Anyone know how to do this?
>
> Thanks,
> Olcay
>

There is never a single right solution here and many books are written on
this single subject. But exposing the shared library to the client kinda
goes against almost everything SOA. This would tightly-couple the client to
the shared lib and hence to the server, and leak implementation details to
the client side (unless the shared lib is nothing but interfaces and
contracts. In which case would not be needed anyway as you could get same
from srvutil.) All of that is explicitly not recommended by soa patterns
(i.e. "four tenents") and all for good reasons that may not be immediately
obvious. Many times, your client side requires different behaviors even for
the same methods. Moreover, your data transfer objects (i.e. DataContracts)
should just be contract and data with zero implementation knowledge or
state. So actually, srvutil does almost exactly what you really want
anyway. You could do the same thing manually, but the tool gives you a head
start. Your service interfaces and DTOs will then be very loosely-coupled
from the server (only related by published contract), which is one of the
main goals of SOA and implementation like WCF. These things trend into
religious debates, so this is only recommended and not carved in stone and
your mileage may vary. Using a shared lib may first appear to save time and
effort, but has many land mines and road blocks (i.e. versioning,
tight-coupling, dependency issues, etc.) as the project grows.

--
William Stacey [C# MVP]
PCR concurrency library: www.codeplex.com/pcr
PSH Scripts Project www.codeplex.com/psobject


<olcayb@gmail.com> wrote in message
news:1171024142.135965.256670@k78g2000cwa.googlegroups.com...
| Hi,
|
| I have a Windows Servicing inlcuding a WCF process which accepts
| "Jobs". I have created a class named "Job" which has different
| properties (FileInfo, String, ... and a generic Queue of another own
| definied class named "VideoCut"). The "Job" and "VideoCut" classes are
| both defined in a 3rd project and both (the server and client) should
| use the classes from the 3rd project and not the via WSDL exposed
| "Job" and "VideoCut" classes.
|
| Anyone know how to do this?
|
| Thanks,
| Olcay
|