WCF服务通常应该是单例服务还是非单例服务？

我相信Jimmy Nillson说过他一般都是把他的Web服务做成单件的。这是首选方法吗？使用WCF？除了使服务方法静态化之外，还有其他事情要做吗？

通常而不是。单件是一团乱，因为要让它们表现良好，你需要让它们多线程，这只是自找麻烦，除非你真的知道自己在做什么

WCF的最佳实践是使用每次调用实例化—每个请求都有自己的服务类副本，没有多线程问题，性能良好—将任何需要持久化的内容存储在数据库中—工作起来很有魅力

单例可能有意义的唯一真实场景是，如果您必须让所有服务请求由仅在单个实例中可用的物理资源使用/处理-如果您的单例服务序列化并因此保护单个资源，那么使用它是有意义的

---

否则-省去麻烦吧！：-）

单例WCF服务几乎不应该被使用-单例是可伸缩性的敌人！它们只在奇怪的情况下才有意义——记录到单个文件、单个通信端口或硬件设备

---

正如Marc所说，WCF可扩展性的最佳选择是每呼叫服务（它们提供了性能和可扩展性之间的最佳权衡）。每次呼叫服务在负载平衡方面也非常有效。

响应良好，但我认为原始问题中存在问题。技术的“典型用途”是一个结构不合理的问题。没有人有“典型”的场景，在决定实现或方法之前，您应该检查特定问题的需求。您的需求应该通知您的解决方案

例如，Singleton[即Singleton模式]只是我们盒子中的另一个工具，与任何工具一样，它在某些情况下有效，而在其他情况下无效。具体来说，如果您需要集中业务逻辑[比远程WCF服务更适用于独立应用程序]或共享内存或资源，那么单例就可以很好地工作。当然，如果您共享业务逻辑，则状态将在调用堆栈中维护，而多线程是没有意义的。如果在使用者调用之间共享内存，则多线程是一个问题。关于WCF，您可以指定多线程行为的两种模式[实际上是三种，但第三种是第一种的特例]

// we are specifying that this service implementation is single-threaded
// and WCF should permit *at most* one call at a time. Any requests made
// simultaneously/concurrently are queued.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
public class SingleThreadedNonThreadSafeService : IService { ... }

及

ConcurrencyMode

的Xml注释基本上与上面所说的内容相同

如果不需要在使用者之间共享业务逻辑或内存，则不使用单例，“模型”不适合此问题。这就像把一只玻璃拖鞋压在继母的脚上！没有人会看到这一点

---

---

相反，如果调用之间没有共享状态，则在每个调用\会话中托管一个实例。

您是否有指向某人使用单例的链接？也许有一个比我们任何人都想不到的更令人信服的原因……这是在他的书《应用领域驱动的设计和模式：C#中的示例》中。是的，这在很久以前就得到了回答，但您能否进一步说明“每次呼叫服务也能很好地处理负载平衡”这一评论？我认为@McArthey指出的是，如果您使用“每次呼叫”服务，您就有机会在多台服务器上分发“呼叫”，而不必担心“状态”。如果他是从主机环境（windows服务、consoleapp）中的访问Hostservice实例发送给客户机-实现单例模式可能更容易；否则，要发送，他需要创建一个客户端，或通过实例提供程序获取实例。-客户端路由可能很有用，但我发现使用已经创建的路由很有效。到目前为止，我还没有遇到线程问题。。而且服务有我需要的性能，而且看起来很稳定。我认为问题所有者的解释被遗漏了。我以为他说的是代理客户端实例，而不是服务本身。在任何情况下，将wcf主机设为单例都没有意义，因为它在设计上是无状态的。我相信他想问的实际问题是：服务消费者使用的WCF服务客户端实例是否应该是单例@苏德乌诺？？？

// we are specifying that this service implementation is multi-threaded
// and [hopefully!] thread-safe. WCF should permit any number of threads,
// or any number of simultaneous concurrent calls.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
public class MultiThreadedThreadSafeService : IService { ... }