Application Structure Using WCF

Question

I have a WPF application, which until now was only a client, but now I am working on its decomposition into client and server parts. In this paper, I introduce WCF for client-server interaction. My application has several projects, and service links are needed from more than one of them.

The initial effort to make the separation is to do everything “directly”. All projects requiring a connection to the service receive a link to the service, as well as the main WPF application project, for receiving app.config there. I find this turning into a mess pretty quickly, and I can’t imagine that this is the typical architecture that people use? I also saw problems with each of the service links generating a new implementation of the DataContract classes, so there is no general understanding of the DataContract classes when crossing projects. I have several ViewModel classes in one project, and another project initiates some ViewModel. I would like to pass the object received from the service, but I cannot, because the generated client representation of the received object is different in each project.

So - is there a recommended way to structure such client / server partitions using WCF? Or do the principles follow? I think that one common proxy project used on the client side, which communicates with services, wraps the received data and returns the data in a form well known to client libraries. Should indicate only one service link, and I think I only need App.config in the wpfApp project? Does this make sense?

Answer 1

I like to structure my WCF solutions as follows:

Contracts (class library)
Contains all service contracts, operations, failures, and data. It can be shared between server and client in a clean .NET-.NET script.

Service implementation (class library)
Contains code for implementing services and any helper / helper methods needed to achieve this. Nothing more.

Service host (optional - may be Winforms, console application, NT service)
Contains a service host for debugging / testing, or possibly also for production.

This basically gives me the server side of things.

On the client side:

Client proxies (class library)
I like to pack my client proxies into a separate class library so that they can be reused by multiple actual client applications. You can do this using svcutil or the “Add Service Reference” and manually configure the awful app.config that you receive or manually implement client proxies (when using the contract assembly) using the ClientBase<T> or ChannelFactory<T> constructs.

1-n actual customers (any application)
Usually it will refer only to the assembly of client proxies, or, perhaps, to the assembly of contracts, if it will be used together. It can be ASP.NET, WPF, Winforms, a console application, other services - you name it.

Thus; I have a beautiful and clean layout, I use it consistently over and over again, and I really think that made my code cleaner and more convenient to maintain.

It was inspired by Miguel Castro Extreme WCF Screen on DotNet Rocks TV with Karl Franklin - highly recommended screening!

Answer 2

It depends. WCF is a large structure and is designed to cover many different scenarios.

But for a simple application like yours, when you don't care about things like the interaction between Java or a common web service, this is what I do:

All DataContract classes and ServiceContract interfaces are part of a library (or libraries) that is shared between the client and server. Note that you probably shouldn’t decorate your Service Implementation with ServiceContract, you would create a separate interface with ServiceContract attributes that you could place in the general assembly.

So you seem to be doing almost everything right. What you probably DO NOT need is the automatic creation of proxies in general. It just hurts you. Therefore, do not use the Add Service Reference dialog box for what you are doing. Just enable your shared DataContract assemblies and use ChannelFactory to get a proxy for your service interface defined in the shared library. It also prevents you from re-generating the proxy server in Visual Studio, which gets VERY FAST for any project with a decent size.

If you go along this route, you can also get rid of the MetaDataExchange endpoint, since this is only necessary to describe the service to the client. Since you are doing everything in the general assembly, you do not need a service description, since you already have a service description in code form.

Answer 3

The usual structure that I use:

General - contains interfaces, data contracts, service contracts, abstract classes, etc .; Client - Common links, contains a server proxy class; Server - Common links, contains the actual implementation classes;