目前我们的解决方案中有12个WCF项目。每个项目本质上都是它自己的端点。例如，“Order”WCF项目是Order.svc端点。这12个端点由单个WebHost项目公开。 WebHost项目有12个.svc文件，指向每个相应的程序集/命名空间。
我的问题围绕着使用一个项目（一个程序集......一个dll）和多个项目（多个程序集......多个dll）。有什么优点/缺点，如果有的话？最终结果是相同的...您有一个WebHost项目，它公开指向程序集/命名空间的这些端点。除了你只需要在bin目录中管理一个.dll vs 12 .dll。
对我来说，一个项目的优势： 可维护性 - 我们有一个项目在一个点上设置了参考，而不是12个项目，每个项目都有多个对我们的接口，数据交换，实用程序等的引用。然后我们可以部署一个dll并利用负载均衡器进行均匀分配。即使我们为每台服务器明确托管3个服务（因此，4个服务器），如果服务器出现故障，负载均衡器也可以调整，其他3个服务器将拥有他们需要的东西并自动处理所有事情。 （我想12个.dll也是如此......只需要确保每个服务器上都有12个.dll。）
构建时间 - 更少的项目=更快的构建时间。 Visual Studio不需要执行尽可能多的链接和复制.dll就到处都是。更快的构建时间=更高效的开发人员和更快的构建和部署。
我目前有几位同事担心将我们所有的WCF服务“紧密耦合”到一个项目中。对我来说，他们都是WCF服务，为什么不将它们放在同一个项目中呢？端点（.svc文件）将它们分开。我也听过这个问题，“死锁怎么办？”。怎么样？这是一个有效的问题/关注吗？ （老实说，我不知道）
还有一些问题是关于.dll是否会变得腐败。如果是，则所有服务都已关闭。再次......这是一个有效的关注点吗？
我从Microsoft和其他人看到的所有示例都在一个项目中将WCF服务分隔为不同的类。接口在他们自己的项目中...在另一个项目中的datacontracts等等。
那么，你有什么看法？如何在Visual Studio解决方案中组织多个WCF服务？跟我学习。
答案 0 :(得分：3)
我们学到了很多困难。我们最近有一个项目，我们从它自己的项目中的每个服务开始，最后转换为在同一个项目中拥有所有服务。在不同项目中拥有东西的主要问题是：
我们对Interfaces（Contracts）和Data Transfer对象使用单独的项目。
答案 1 :(得分：1)
一般来说，如果我的svc文件存在于同一个程序集中，那么它们就是共享一些目的。如果svc共享足够的共同目的存在于同一个程序集中，那么实现也有足够的共同目的存在于单个程序集中。
将它们放在单独的组件中没有任何问题，但也没有任何好处。它更多的是建立一个结构清晰，可维护的解决方案 - 而且主要是个人偏好/标准/风格问题。
如果您通常将实施分开，则将实施分开 - 也就是说，如果它们提供显着不同的结果或作为解决方案的单独组件。如果单个组件不实用，则将其分开。
更多地关注合同和实施。它们服务于不同的（技术）目的，您可能希望在不暴露实现的情况下公开合同。
说了这么多之后，我宁愿将它们放在一个组件中，而是通过明确的命名空间分开。较少的装配通常更容易管理。
答案 2 :(得分：0)
请记住，您不必像管理开发一样部署项目。作为构建步骤的一部分，您始终可以使用ILMerge之类的东西将dll多个dll放入一个dll中。
我总是建议使用软件工厂（也称为Web服务软件工厂）http://servicefactory.codeplex.com/来开发一些服务，这有助于从MSFT模式和工具中强制执行一系列“最佳实践”。实践团队。这是学习一些最佳实践的好方法，但是一旦你学习了它们，通过开发团队通过良好的指导/代码审查来强制执行它们通常会更好/更容易。通过这种方式，您可以使用在您的环境中有效的方法，而不是使用阻碍的方式。
如果你有12项服务，你如何管理可能发生的配置地狱？特别是当您拥有依赖其他服务的服务时。最终将所有这些以及任何自定义绑定和行为放入配置可能是部署的噩梦。另外，如何让企业中的其他人了解您的服务？这些都是通过口口相传，良好的构建管理和源代码控制来完成的吗？