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>".
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.
Senior Software Engineer
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...
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.