Multiple WCF Projects vs Single Project in Solution

Question

Currently we have 12 WCF projects in our solution. Each project is essentially it's own endpoint. For example the "Order" WCF project is the Order.svc endpoint. These 12 endpoints are exposed by a single WebHost project. The WebHost project has 12 .svc files pointing to each corresponding assembly/namespace.

My question revolves around using ONE project (one assembly... one dll) vs multiple projects (multiple assemblies... multiple dlls). What are the advantages / disadvantages, if any? The end result is the same... you have a WebHost project that exposes these endpoints pointing to a assembly/namespace. Except you just have to manage one .dll vs 12 .dll's in the bin directory.

To me the advantages to one project: Maintainability - instead of 12 projects, each with multiple references to our interfaces, datacontracts, utility, etc., we have one project that has the references set in ONE spot. We then can deploy out the one dll and utilize a load balancer to distribute evenly. Even if we explicitly host 3 services per server (so, 4 servers), if a server goes down the load balancer can adjust and the other 3 servers will have what they need and take care of everything automagically. (I guess the same is true with 12 .dll's... just have to make sure all 12 .dll's are on each server).

Build time - fewer projects = quicker build time. Visual studio doesn't have to perform as much linking and copying .dll's all over the place. Quicker build time = more productive developer and a quicker build and deploy.

I currently have a couple co-workers concerned about "tightly coupling" all our WCF services into one project. To me, they are all WCF services why not put them in the same project? The endpoints (.svc files) are what separate them out. I have also heard the question, "what about dead lock?". What about it? Is that a valid issue / concern? (I honestly don't know)

There have also been questions raised about if the .dll becomes corrupt. IF it is, then all the services are down. Again... is this a valid concern?

All the examples I've seen from Microsoft and others have the WCF services in one project separated by different classes. Interfaces are in their own project... datacontracts in another project and so on.

So, what is your take? How do you organize multiple WCF services in your Visual Studio Solution? Learn me.

Answer 1

We learned this the hard way. We recently had a project where we started with each service in it's own project and ended up converting to have all services in the same project. The main problems with having things in different projects are:

• Deployment: Do you create 12 msi packages one for each service, will they be deployed to seperate web sites. What does opperations think about running 12 install scripts and monitoring 12 sites.
• Do the services call each other, if yes then over WCF can be slow and the configuration can be a nightmare, 12 services calling 11 services, with configuration for dev, test and prod.
• Also on services calling each other there is a performance hit compared with a direct dll call
• Do the services have a common version, when for example the database changes will all services change. If yes you will allways need to deploy all services. This takes longer than a single service, your down time will be longer

We use seperate projects for Interfaces (Contracts) and Data Transfer objects.