WCF 设计：同时使用：会话和每次调用机制？
我要使用 WCF 设计一个 Web 服务，它产生不需要会话的方法（例如静态调用，例如：返回有关 Web 服务本身的一些信息）和其他需要会话的方法。
此外，基于会话的方法正在使用应该能够在运行时更改的工作流程。
我当前的设计如下：
有一个在 IIS 中运行的单例服务，它处理所有每次调用方法，该方法也充当基于会话的服务的主机。这样，单例类就知道所有会话，并可以停止正在运行的工作流来交换它们。
这是一个好的/可能的设计选择吗？
这是使用通用设计的常见场景吗？
我会对任何阅读提示感到高兴，因为 msdn 帮助对我来说没有多大帮助。
谢谢你的回答
-重做
I am to design a webservice using WCF that yields methods that don't require a session (like static calls, eg: giving back some information about the webservice itsself) and other methods that require a session.
furthermore, the session based methods are using Workflows that are supposed to be able to be changed at runtime.
my current design would look like this:
there is a singleton service that runs in IIS that handles all the per call methods which also works as a host for the session based services. that way the singleton class knows about all the sessions and can halt the running workflows to exchange them.
is this a good/possible design choice?
is this a common scenario that uses a common design?
would be happy about any reading hints as the msdn help wasn't such a help to me.
thanks for your answers
-redoced
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用单例 WCF 服务类几乎从来都不是一个好主意 - 除非您确实只有一个（物理）资源并希望防止并发访问，否则它实际上没有意义。
因为：要么它不具备多线程能力，但在这种情况下，它成为一个巨大的瓶颈 - 请求严格按顺序处理 - 一个接一个。对于性能来说不太好。
或者，您需要使整个服务具有多线程意识 - 让我告诉您，正确、安全且高效地实现这一点并不适合胆小的人。要做到这一点并使其表现良好确实非常困难。
我真的不认为有任何必要。
将“静态”消息调用（如您所称的那样）保留为每次调用服务 - 这些服务易于编程、工作良好、性能良好，永远不会导致任何多线程问题
那些确实需要的少数服务调用（希望如此！）会话 - 将它们放在自己的服务端点上，将它们设置为每个会话，在会话中使用“SessionId”来识别它们。这比每次调用要多做一些工作 - 但仍然远不及多线程编程那么复杂和容易出错
WCF 会话资源：
WCF 持久服务的资源（在调用之间保留其状态）：
WCF 工作流服务资源：
Using a singleton WCF service class is almost never a good idea - unless you really have just one single (physical) resource which you want to protect from concurrent access, it doesn't really make sense.
Because: either it's not multi-threading capable, but in this case, it becomes a huge bottleneck - requests are handled strictly sequentially - one after another. Not very good for performance.
Or then you need to make the whole service multi-threading aware - and let me tell you, making this properly, safely, and efficiently isn't for the faint of heart. It's really really hard to get this right, and make it perform well.
I really don't see any need for this, at all.
leave you "static" message calls (as you call them) be per-call services - those are easy to program, work well, perform well, never cause any multithreading issues
those few service calls (hopefully!) that do require a session - put them on their own service endpoint(s), make them per-session, use the "SessionId" in your session to identify them. It's a bit more work than per-call - but still nowhere near as complicated and error-prone as multi-threaded programming
Resources for WCF sessions:
Resources for WCF durable services (that persist their state between calls):
Resources for WCF Workflow Services: