我们目前正在审查我们的WCF服务设计，困扰我的一件事是Per-Call和Per-Session服务之间的决定。我相信我理解这两者背后的概念，但我并没有真正看到Per-Call服务的优势。我理解使用Per-Call服务的动机是WCF服务仅在调用期间保存服务器对象，从而限制服务实例持有昂贵资源的时间，但对我而言，它更易于使用类似于OO的每会话模型，其中您的代理对象实例总是与同一服务器对象实例相对应，并且只是手动处理任何昂贵的资源。
例如，假设我有一个带有添加，更新，删除，选择方法的CRUD服务。这可以作为具有数据库连接的Per-Call服务（“昂贵的资源”）在服务器对象构造函数中实现。或者，它可以是一个每会话服务，在每个暴露的CRUD方法中实例化并关闭数据库连接。
对我而言，资源方面没有什么不同，它使编程模型更简单，因为客户端可以确保它们的代理服务器对象总是具有相同的服务器对象：保持调用之间可能存在的任何昂贵状态对于识别服务在再次实例化新服务器对象时必须检索哪些状态数据的方法，不需要额外的参数（如Per-Call的情况）。它就像使用相同资源管理问题的类和对象一样，但是我们不为每个对象上的方法调用创建新的对象实例！
那么我对Per-Call模型缺少什么？
由于
答案 0 :(得分：10)
就PerCall或PerSession而言，没有正确或错误的优点和缺点。您似乎正在从面向对象的角度接近PerSession自然适合的观点。典型的SOA方法是PerCall方法。
在所有条件相同的情况下，权衡是性能与可扩展性。 PerSession应该执行得更好，因为对象不必在后续请求中实例化。 PerCall应该更好地扩展，因为在服务器上实例化的唯一对象正在进行实际工作。它不仅仅是“昂贵的”资源，而是服务器上打开的所有会话。例如在PerSession情况下，您可能在服务器上实例化了1000个对象，但实际上只有100个实际处于调用状态。但是，在PerCall情况下，只有100个对象被实例化为100个调用。实例化的PerSession对象可能浪费资源，并可能影响在负载下提供请求的能力。
如果我的服务公开曝光，我也不愿相信我的对象生命周期对服务消费者的一时兴起;我担心我的服务可能被恶意代码或错误代码删除。
PerCall方法的另一个潜在好处是系统可用性。回到上一个示例，如果PerSession服务器崩溃，那么在该服务器上有会话的所有1000个客户端将丢失其会话并且无法完成其工作。在PerCall情况下，唯一会发生的错误是对正在进行的100个实际请求（假设快速故障转移）。其他900个客户端可以在下次呼叫时路由到另一台服务器。这对SLA来说很重要。
答案 1 :(得分：6)
简而言之，答案将是无状态和可扩展性。
如果您了解服务将如何使用的环境，则每个会话都可以正常运行，是的，您可以共享资源，从而使服务具有状态。当您需要引入故障安全服务器，负载平衡和路由服务调用时，会话服务将出现问题，因为调用并不总是解析为同一服务对象。此外，如果客户端使用的服务未修复工作流，那么您如何知道何时释放该会话的服务对象？大多数时候你依赖租约超时但是在负载很重的环境中，这也会在内存中创建对象和空闲时产生问题。
在设计方面，将服务呼叫相互独立也是一种好习惯。因此，您不必依赖先前的服务调用来设置对象的状态。