tags:

views:

179

answers:

1

I have a Visual Studio solution containing a web site project plus a bunch of supporting projects (domain model, data access, etc).

I want to expose an API to the same underlying data, via urls under the same domain, so I developed a WCF/REST project to do this (which has dependencies on the same set of domain/data access projects).

Now I'm wondering what the pros and cons are of having the WCF service in a separate solution, deployed under a virtual IIS path, compared with just putting the WCF project into the original website solution.

Are there good reasons why I would want to go one way or the other? I'm not too experienced with IIS deployments.

+2  A: 

IF you ever want to self-host the service instead of hosting it inside IIS, or if you ever want to share the service interface as an assembly for some reason, it will probably be easier to have it in a separate assembly.

I would recommend one assembly for the service interface(s) (including data contracts and such), one for the service implementation, and another (if needed) for a self-host (e.g. Windows NT service or command-line app). That's the cleanest separation and there's no real reason not to go that way, IMHO.

Marc

marc_s
I concur. Several times I've included my .svc file in the web project but I always hold the contract in a common file and concrete service implementation in a service project. This saved my bacon in the exact way Marc talks about. In addition, if your contracts are in a seperate library, you can distribute it without giving up your business logic.
Joshua Belden