RX 主题 - 要避免它们吗？答案

【问题标题】：RX Subjects - are they to be avoided?RX 主题 - 要避免它们吗？
【发布时间】：2016-07-17 10:56:34
【问题描述】：

我在另一个线程中有一个mini-discussion on the topic，希望人们对主题的“坏”方面提出意见。

经常访问 RX 论坛的人都知道E.Meijer does not like Subjects。虽然我非常尊重 RX 创建者的意见，但几年来我一直在多个项目中广泛使用主题，并且没有因为它们而出现任何架构问题或错误。

我能说出 Subjects 的唯一“缺陷”是它们不是“可重用的”——在完成 Subject 的 observable 之后，您需要重新实例化它，然后新订阅者才能从它接收事件。

“代码异味”和“不喜欢它们”需要“实用”示例来支持 - 您能否提醒我们注意使用主题时可能导致错误或问题的情况？或者您可能认为它们完全简单且无害 - 然后尝试定义它们的使用区域。

【问题讨论】：

【解决方案1】：

Erik Meijer 以纯粹的函数方式思考 - 主题是 Rx 的可变变量。所以，在一般用法中他是对的——使用主题有时是一种逃避功能思考的方式，如果你使用它们太多，你就会试图逆流而上。

但是！当您与 .NET 的非功能世界交互时，主题非常有用。包装事件或回调方法？主题非常适合。试图将 Rx“接口”放到一些现有代码上？使用主题！

【讨论】：

听起来很合理。除了我建议已经有一些方法来包装事件，即 Observable.FromEvent(Pattern) 这又比主题更可取。
我相信他不仅仅意味着简单地包装事件和异步调用，而是使用来自它们的数据。例如，包装 BeginRead/EndRead 对异步调用 - EndRead 仅返回读取的字节数，以获取您必须访问传递给 BeginRead 的可变字节数组的实际数据。跨度>
我实际上倾向于认为将 Subject 预先作为公共 API 的一部分是一个糟糕的想法，因为您暴露了一个具有双重责任的易受攻击的对象，因此违反了分离原则客户的担忧，他们可能会调用任何OnNext、OnCompleted、OnError lambdas。
@PaulBetts：我也很想知道你用主题来包装事件是什么意思？能否提供一个代码 sn-p？

【解决方案2】：

似乎很多评论者都在互相交谈。

上次我使用 Subject 是当我需要在初始化调用中将委托传递给中间件时，它可以在发生某些事情时回调我。委托具有熟悉的事件 args 签名，但我无法使用 FromEvent，因为没有事件。

我并没有为此感到难过 - 我没有看到任何其他选择。

基本上，我仅在发起某个事件并将其放入 Rx 世界时，或者当我需要处理某个尚未到达的未来订阅者时才使用主题。主题让我将我现在拥有的内容链接到以后的订阅者。

【讨论】：

我从您的评论中推断出Observable.FromEvent 方法当时不适合普通代表。或者他们可能仍然 dont and they do mandate that the thing be an event` 而不仅仅是一个代表。我得去看看那个。但是你能发布一些代码来展示你做了什么吗？我很想了解您使用Subject<T> 的方式。

【解决方案3】：

每当响应式组合器由于惰性评估而被复制时，我都会使用Subject/Publish。

但是，对于随意使用，我觉得主题有点重 - OnNext 可能是潜在的瓶颈 - 在分析期间显示为热点，可能是因为在向订阅者推送值时进行并发检查。

我觉得它对 Observables 来说也更干净，因为你知道根据定义是热门的。

【讨论】：

【解决方案4】：

我对使用Subject<T> 作为公共 API 的一部分持谨慎态度的一个原因是它混合了关注点；观察者是不同于可观察者的关注点。

如果某些恶意观察者在应该只是观察者的Subject<T>上调用OnNext或OnCompleted或OnError怎么办？

即使它不是 API 的一部分，并且您将它作为私有支持字段隐藏在服务器中，但它具有双重角色的事实本身就令人不安。在将其用作支持字段的情况下，您仍然只期望它执行一个角色/关注点——可观察的角色/关注点。然而，它有可能做两件事，这只是精神上的不安。

【讨论】：