C# 事件与 WCF/SOA Pub-Sub 服务的比较：保护对象免受订阅者的侵害
在过去 2.5 年中完成了大量 WCF 服务和 SOA 开发，包括构建每次调用的发布-订阅服务，其中关键原则之一是开发人员应该努力构建纯粹的客户端-服务器关系，其中两个客户端都不了解其内部结构服务...他们应该只知道接口，而服务不应该依赖于或特定于单个客户端的细节，这让我想到这如何应用于 C# 自己的发布订阅系统：事件处理程序。事实上，这个问题适用于任何类似的语言。
在我看来，公开事件然后调用这些事件的对象与 SOA 世界中的发布-订阅服务没有什么不同。本质上，在 C# 中调用事件就像“服务”调用其依赖项“客户端”之一上的方法。当我们在 WCF 中构建发布-订阅服务时，对客户端的回调始终是异步完成的（防止客户端可能阻塞服务），并且隔离因通信或未处理的客户端异常而导致的任何故障，再次保护服务免受客户端影响。
为什么 .NET 中的做法不是同时异步触发事件并始终在事件处理程序中处理（并吞掉？？？）异常？根据我的经验代码，事件调用者依赖于处理程序的成功是糟糕的设计......您应该为您所依赖的事物调用方法。当然，暴露事件的对象并不关心处理程序需要多长时间来完成他们的工作......或者他们是否成功？
讨论！
Having done alot of WCF services and SOA development over the last 2.5 years including building per-call publish-subscribe services where one of the key principals is that developers should strive to build pure client-server relationships where both clients are ignorant of the internals of a service...they should only know the interface and services should have no dependancies on or details specific to individual clients, it made me think of how this applies to C#'s own publish-subscriber system: event handlers. Really this question applies to any comparable language though.
As I see it objects that expose events and then call those events are no different to pub-sub services in the SOA world. Essentially calling events in C# like is a "service" calling a method on one of its dependants "client". When we built pub-sub services in WCF, callbacks to clients were always done asynchronously (preventing a client from possibly blocking the service) and any faults resulting from communication or unhandled client side exceptions were isolated, again to protect the service from its clients.
Why is it not the practice in .NET to also fire events asychronously and to always handle (and swallow???) exceptions in event handlers? In my experience code where an event caller depends on the success of a handler is poor design...you should be calling methods for things you depend on. Surely an object exposing an event doesnt not care either how long the handlers take to do their work...or if they even succeed?
Discuss!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最终，在设计语言时需要考虑很多设计因素。现在我可以想到以目前的方式实现事件的一些具体论据：
首先，简单性。实现即发即忘系统使得作为编码员几乎不可能实现即发即反应系统。然而，实施即发即反应系统可以轻松实现即发即忘系统。除此之外，事件非常简单。事件只是多播委托，只有声明类才能触发它们。不多不少。
其次，.NET Core 框架中的一些代码依赖于事件系统以及 Fire 和 React 系统。例如，Winforms BeforeExit 事件可以在事件参数中取消。
Eventually there are many design considerations to be made when designing a language. Now i can think of a some concrete arguments for implementing events the way it currently is:
First of all, the simplicity. Implementing a fire and forget system makes it almost impossible to implement, as a coder, a fire and react system. However, implementing a fire and react system makes it easily possible to implement a fire and forget system. Next to that, events are very straight forward. Events are just multicast delegates where only the declaring class can fire them. Nothing more, nothing less.
Secondly, some code in the .NET core framework rely on the event system in conjuction with a fire and react system. For example the Winforms BeforeExit event which has the possibily to cancel in the event Arguments.