为什么使用有状态 Web 服务是不好的编程以及为什么会允许这样做？
我的组织需要有状态的 Web 服务。 然而，我在网上读到的所有内容都说构建有状态的 Web 服务是糟糕的编程，但没有任何说明原因。 我想我不明白这有什么不好。 我也不太明白为什么他们会想办法让你在网络服务中拥有状态。
所以我想我的问题是，为什么使用有状态的 Web 服务是不好的编程以及为什么会允许它？
I have a need for a stateful webservice in our organization. However, everywhere I read online says that building a stateful webservice is bad programming but nothing ever says why. I guess I don't understand what is so bad about it. I also don't really understand why they would give a work around to allow you to have state in a webservice.
So I guess that my question is, why is it bad programming to use a stateful webservice and why would it be allowed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Web 服务的全部目的是以高度可扩展的方式在一次事务中提供一项功能。 这意味着保持事情简单和原子。
当您必须进行多次调用来执行操作时，您很可能会导致事务挂起。 客户回来了吗？ 他们完成了吗？ 交易应保持多长时间？ 他们坠毁了吗？ 回滚应该如何处理？
这些问题的答案可能会对运行服务所需的资源产生根本性的影响。 这就是为什么每个人都建议一次性完成这一切。
The whole purpose of a web service is to deliver a piece of functionality in one transaction in a way that is highly scalable. This means keeping things simple and atomic.
When you have to make multiple calls to perform the operation, you have a great potential of leaving transactions hanging. Is the client coming back? Are they done? How long should the transaction remain open? Did they crash? How should rollbacks be handled?
The answers to these questions could have a radical impact on the resources necessary to run your service. Which is why everyone recommends doing it all in one swoop.
以下是我能想到的一些原因：
维护状态的成本只能由服务器端承担 - 服务使用者很少是 Web 浏览器，因此没有 cookie。 这会降低服务器性能并增加设计复杂性。
服务消费者是一个智能程序，而不是一个愚蠢的浏览器。 因此，程序将（几乎总是）维持其自己的状态。 换句话说，当您提供服务时，您的消费者将准确请求他们想要的数据。 在服务器上维护状态变得过时且不必要。
事务 - 服务是系统中的一个悬挂点，因为它的客户端大多是智能的，它们决定何时通知您其状态的变化。 这意味着，如果您维护状态，则可能必须在服务调用之间等待才能完成事务操作。 并且绝对不能保证客户端会进行下一次服务调用。
原因有很多，但这些是我能立即想到的:)
Here are some reasons I can think of:
The cost of maintaining state will have to be borne server side only - service consumers are rarely web browsers, so have no cookies. This brings down your server performance and increases your design complexity.
A service consumer is an intelligent program, rather than a dumb browser. As such the program will (almost always) maintain its own state. In other words, when you provide a service, your consumer will request precisely the data it wants. Maintaining state on the server becomes obsolete and unnecessary.
Transactions - a service is a dangling point in your system because its clients are mostly intelligent, and they decide when to inform you of changes in their state. This means that if you maintain state, you might have to wait between service calls to finish a transactional operation. And there's absolutely no guarantee the client will ever make that next service call.
There are a lot of reasons, but these are the ones I can think of off the top of my head :)
我认为这是一种神话
如果谷歌可以使他们的有状态网络应用程序可扩展，那么为什么我们不能扩展有状态网络服务。 这一切都与应用程序服务器有关，这降低了可扩展性。
即使有了网站或网络服务，最终目标也是提供更好的服务。 如果“有状态”是为了改善您的服务，那么请毫不犹豫地选择它。
I think it is a kind of myth
If google can make their stateful web application scalable, then why cant we scale a stateful webservice. It is all about the app server which reduces the scalability.
Even with a website or webservice, ultimate aim is to serve better. If a "stateful" is to improve your service, then don't hesitate to go with that.