Using shared DataContract between client and Service

Hi,

  I am building a system whereby the architecture is as follows:-

1) Client application -
      
         i) Business layer
         ii) Domain Layer
         iii) Data Access Layer

2) WCF Service:-

         i) Service layer
         ii) Domain Layer (with data contracts) - This is a shared
             assembly with the Client containing all the types

Problem is , in the client when I get to adding a Service reference, it recreates all the data contract types with a completely different namespaces.

So from my client/business layer when i try to call a Operation in my WCF, it complains "cannot convert type <my domain layer> to <The proxy namespace type>".

Please help.

Regards,
Sumit

Hi Sumit,

 In order to fix your problem, you'll have to use the command line tool, svcutil.exe to generate the proxy code.

With the /reference (or /r for short) switch, you can specify assemblies that contains shared types.

(You will probably use the /target:code (or /t) switch - to generate
 your proxy class).

 Run svcutil.exe without any arguments to view the help - or look it up in the MSDN documentation.

 

 Regards,

 Lars Wilhelmsen
 Senior Software Engineer
 Norway

A major point is that you should not share clr types.  You share interfaces/contracts.  Ref dlls is a dead end and against SOA tenants for many good reasons.  The basic idea is that you build your server with your types as needed and expose the types client needs with datacontract.  Then your client runs svcutil in create the matching types.  Then change types as needed.  The main thing is, the client still has his own types and server has his types.  They are wire compatable, but not binary compatable which allows things like versioning and loose-coupling, etc.

If you're building "both sides of the gap" / or if you are building a reference implementation, I can't see why it would harm if you to reuse your business entities in both the server and client.

I know it's against "the 4 tenets" to do so, but hey! He asked how he could do it...

Regards,

Lars Wilhelmsen