Multiple WCF Projects vs Single Project in Solution_问答_开发者

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... dat开发者_开发百科acontracts 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.

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.

Generally if my svc files exist in the same assembly, then they are sharing some purpose. If the svc share enough common purpose to exist in the same assembly, then the implementation also shares enough common purpose to exist in a single assembly.

There's not any problem with having them in separate assemblies, but there's not any benefit either. It is more about building a clearly structured, maintainable solution - and is largely a personal preference / standards / style question.

Separate the implementations if you would normally separate them - that is, if they give significantly different outcomes or act as separate components of your solution. If the single assembly would be unwieldy then separate it out.

Focus more on contracts and implementations. They serve different (technical) purposes and you may want to expose the contracts without exposing the implementations.

Having said all that, I'd rather have them in a single assembly but separated by clear namespacing. Less assemblies is often easier to manage.

Remember, you don't have to deploy your projects the same way you manage their development. You can always use things like ILMerge to mutiple dlls into one dll, as part of a build step.

I always recommend developing some services using the Software Factory (aka the Web Service Software Factory), http://servicefactory.codeplex.com/ which helps to enforce a bunch of "best practices" from the MSFT Patterns & Practices team. It is a great way to learn some best practices, but once you learn them it is usually better/easier to just enforce them thru good guidance/code reviews with your development team. This way you can use what works in your environment, and not use what gets in the way.

If you have 12 services, how do you manage the config hell that can occur? Especially when you have services that depend on other services. Eventually putting all that, and any custom bindings and behaviors, into the config can be a deployment nightmare. Also, how do you make your services known to others in the enterprise? Is all done via word of mouth, good build management and source control?