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

目前,我们的解决方案中有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服务？向我学习.