WCF Project vs. A folder in the existing website project?

What way makes the most 开发者_如何转开发sense? I have a ASP.NET app... and maybe a Silverlight app in the future.. I want both to talk to web services..

At first, I like have the WCF project be by it self for the seperation..

But then I thought.. What is the point since I can just as easily have a 'WEBSERVICES' folder that contains all the .svc files and code in the EXISTING website project. ... Atleast that way.. deploying to a remote host will be a little easier since everything is in one project..

any other considerations ?

---

Why not have:

• your WCF service and data contracts in a Contracts assembly
• your WCF service implementations in a Services assembly
• reference those two assemblies from your web site or web app
• put the *.svc files into a WebServices directory

That way, you have

• clean and nicely organized separation of concerns
• the deployment files (*.svc) are in your web site / web app as you want
• you can still extend / use your WCF code in other ways (e.g. self-hosting) later on without much fuss

---

Two things to consider:

Security - are your services only going to be used by your application, or do they have the potential to be used anywhere else (after all they are services). If so, you will be granting access to your application in order to grant access to your web services, or at least tweaking the access to that specific folder, which might lead to security breaches.

Deployment - If you do changes on your service that doesn't break the contract, in order to deploy the changes you will have to deploy the whole application.

I would prefer to go with the approach that Marc suggested (e.g. have an assembly for contracts, one for the service implementation) and have the webservice hosted as its own application and reference it from the ASP.NET app. This way, you have proper separation of concerns and can maintain both separately.