我们目前正在审查 WCF 服务设计，困扰我的一件事是 Per-Call 和 Per-Session 服务之间的决定。我相信我理解两者背后的概念，但我并没有真正看到按呼叫服务的优势。我知道使用 Per-Call 服务的动机是 WCF 服务仅在调用生命周期内保存服务器对象，从而限制服务实例保存昂贵资源的时间，但对我来说，它使用起来更简单更像面向对象的每会话模型，其中代理对象实例始终对应于同一服务器对象实例，并且只需手动处理任何昂贵的资源。
例如，假设我有一个 CRUD 服务，其中包含添加、更新、删除、选择方法。这可以作为每次调用服务来完成，并在服务器对象构造函数中实例化数据库连接（“昂贵的资源”）。或者，它可以是每会话服务，在公开的每个 CRUD 方法中实例化和关闭数据库连接。
对我来说，这在资源方面没有什么不同，它使编程模型更简单，因为客户端可以放心，他们的代理始终具有相同的服务器对象：维护调用之间可能存在的任何廉价状态，并且没有额外的参数方法上需要确定服务再次实例化新服务器对象时必须检索哪些状态数据（如 Per-Call 的情况）。就像使用类和对象一样，其中存在相同的资源管理问题，但我们不会为对象上的每个方法调用创建新的对象实例！
那么 Per-Call 模型缺少什么？
Thanks
就这一点而言，没有对错之分PerCall or PerSession只是不同的优点和缺点。您似乎是从面向对象的角度接近的，其中PerSession是天作之合。一个典型的SOA方法将是PerCall方法。
在所有条件相同的情况下，需要权衡性能与可扩展性。PerSession应该表现得更好，因为该对象不必在后续请求中实例化。PerCall应该可以更好地扩展，因为在服务器上实例化的唯一对象正在执行实际工作。它不仅仅是“昂贵”的资源，它还包括服务器上打开的所有会话。例如在一个PerSession在这种情况下，您可能在服务器上实例化了 1000 个对象，但任何时候实际上只有 100 个对象在调用。然而，在一个PerCall在这种情况下，100 次调用只会实例化 100 个对象。实例化PerSession对象可能会浪费资源，并且可能会影响在负载下处理请求的能力。
如果我的服务被公开暴露，我也不愿意相信我的对象生命周期取决于服务消费者的突发奇想；我担心我的服务可能会被恶意或有错误的代码所破坏。
另一个潜在的好处PerCall方法是系统可用性。回到前面的例子，如果PerSession如果服务器崩溃，那么在该服务器上拥有会话的所有 1000 个客户端都将丢失会话并且无法完成其工作。在里面PerCall在这种情况下，唯一会发生的错误是针对正在进行的 100 个实际请求（假设快速故障转移）。其他 900 个客户端可以在下次呼叫时路由到另一台服务器。这对于 SLA 可能很重要。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
