I’m planning on creating wrappers for my WCF client which encapsulate calls to a WCF Service.
The Wrappers would instantiate proxies (using the Service References generated classes), deal with errors returned by the Service and forward them back to the caller. The Wrappers would also create DTOs from Business Objects and vice-versa.
For example, a Login’s View View-Model would call a Login Wrapper’s “Login” method when a button is clicked. The View-Model would pass the Username and Password to the Wrapper, which would create a new Data Transfer Object (DTO). The Wrapper would then invoke the “Login” service contract on my Service, pass in the DTO, and return the action’s result to the caller (i.e.: Login Successful / Failed).
Since I’m using an IoC Container (Unity) to inject the Wrappers in my View Models, I would need to create an Interface for the Wrappers.
It occurred to me that the Interfaces that I would create might as well impose the methods that the Wrappers would implement.
In that regard, should the project that define the Wrappers have a reference to the Web Service’s assembly which defines the Service Contracts ?
The Wrappers would then implement the appropriate Service Contracts. For example, a UserManagementProxyWrapper class would implement an IUserManagement service contract defined in an assembly also used by the Web Service.
Would this be an acceptable approach ? Does the fact that the Interfaces have WCF attributes (i.e.: ServiceContracts / DataContract) have any impact on the Wrappers’ implementation ?
That would be an appropriate solution if you want the same input/output arguments as the WCF data contracts. It won’t make absolutely any difference the fact that those interfaces are decorated with attributes.