解决方案中的多个 WCF 项目与单个项目

Question

目前，我们的解决方案中有 12 个 WCF 项目。每个项目本质上都是它自己的端点。例如，“Order”WCF 项目是 Order.svc 端点。这 12 个端点由单个 WebHost 项目公开。 WebHost 项目有 12 个 .svc 文件指向每个对应的程序集/命名空间。

我的问题围绕着使用一个项目（一个程序集...一个 dll）与多个项目（多个程序集...多个 dll）。如果有的话，有什么优点/缺点？最终结果是相同的......您有一个 WebHost 项目，该项目公开了这些指向程序集/命名空间的端点。除非您只需要在 bin 目录中管理一个 .dll 与 12 个 .dll。

对我来说，一个项目的优势： 可维护性——不是 12 个项目，每个项目都对我们的接口、数据合同、实用程序等有多个引用，我们有一个项目在一个地方设置了引用。然后我们可以部署一个 dll 并利用负载均衡器来平均分配。即使我们明确地为每台服务器托管 3 个服务（即 4 台服务器），如果一台服务器出现故障，负载均衡器也可以进行调整，而其他 3 台服务器将拥有他们需要的东西并自动处理所有事情。 （我想 12 个 .dll 也是如此……只需确保所有 12 个 .dll 都在每台服务器上）。

构建时间 - 更少的项目 = 更快的构建时间。 Visual Studio 不必在各处执行尽可能多的链接和复制 .dll。更快的构建时间 = 更高效的开发人员以及更快的构建和部署。

我目前有几个同事担心将我们所有的 WCF 服务“紧密耦合”到一个项目中。对我来说，它们都是 WCF 服务，为什么不把它们放在同一个项目中呢？端点（.svc 文件）将它们分开。我也听到过这样的问题，“死锁怎么办？”。怎么样？这是一个有效的问题/担忧吗？ （我真的不知道）

还有关于 .dll 是否损坏的问题。如果是，则所有服务都已关闭。再次......这是一个有效的担忧吗？

我从 Microsoft 和其他公司看到的所有示例都将 WCF 服务放在一个项目中，并由不同的类分隔。接口在他们自己的项目中......另一个项目中的数据合约等等。

那么，你的看法是什么？如何在 Visual Studio 解决方案中组织多个 WCF 服务？学我。

Answer 1

我们很难学到这一点。我们最近有一个项目，我们从它自己的项目中的每个服务开始，最终转换为在同一个项目中拥有所有服务。在不同项目中拥有东西的主要问题是：

• 部署：您是否为每个服务创建 12 个 msi 包，它们将部署到单独的网站。运营商对运行 12 个安装脚本和监控 12 个站点有何看法。
• 服务是否相互调用，如果是，则通过 WCF 可能会很慢，配置可能是一场噩梦，12 个服务调用 11 个服务，配置用于开发、测试和生产。
• 此外，在相互调用的服务上，与直接 dll 调用相比，性能也会受到影响
• 服务是否有一个通用版本，例如当数据库更改时，所有服务都会更改。如果是，您将始终需要部署所有服务。这比单个服务需要更长的时间，您的停机时间会更长

我们为接口（合同）和数据传输对象使用单独的项目。

Answer 2

一般来说，如果我的 svc 文件存在于同一个程序集中，那么它们共享某些目的。如果 svc 共享足够多的共同目的以存在于同一个程序集中，那么实现也共享足够多的共同目的以存在于单个程序集中。

将它们放在单独的程序集中没有任何问题，但也没有任何好处。它更多是关于构建一个结构清晰、可维护的解决方案 - 很大程度上是个人偏好/标准/风格问题。

如果您通常将实现分开 - 也就是说，如果它们给出明显不同的结果或充当解决方案的单独组件，则将它们分开。如果单个组件笨重，则将其分开。

更多地关注合同和实施。它们服务于不同的（技术）目的，您可能希望在不公开实现的情况下公开合同。

说了这么多，我宁愿将它们放在一个程序集中，但用清晰的命名空间分隔。较少的程序集通常更易于管理。

Answer 3

请记住，您不必像管理项目开发那样部署项目。作为构建步骤的一部分，您始终可以使用 ILMerge 之类的东西将 dll 转换为一个 dll。

我始终建议使用软件工厂（又名 Web 服务软件工厂）http://servicefactory.codeplex.com/ 开发一些服务，这有助于实施 MSFT 模式和实践团队的一系列“最佳实践”。这是学习一些最佳实践的好方法，但是一旦你学会了它们，通过与你的开发团队的良好指导/代码审查来执行它们通常会更好/更容易。通过这种方式，您可以使用在您的环境中有效的东西，而不是使用妨碍您使用的东西。

如果您有 12 个服务，您如何管理可能发生的配置地狱？尤其是当您的服务依赖于其他服务时。最终将所有这些以及任何自定义绑定和行为放入配置中可能是部署的噩梦。此外，您如何让企业中的其他人知道您的服务？都是通过口耳相传、良好的构建管理和源代码控制完成的吗？