【问题标题】:.NET 3.5 stand-in for System.IObserver<T>System.IObserver<T> 的 .NET 3.5 替代
【发布时间】:2010-07-20 02:11:37
【问题描述】:

我想将 .NET 4.0 接口 IObserver 用于需要支持以前版本的框架的库。我已经有了条件编译,可以为每个框架版本进行构建。

我不想使用 Rx Extensions 的 IObserver&lt;T&gt; 版本,因为这会给原本独立的程序集添加不必要的依赖项。

我正在考虑将这段代码添加到我的库中,我对你们所有人的问题是:

1) 我知道这是个坏主意,但我想弄清楚,“为什么?”

#if !NET40
namespace System
{
    public interface IObserver<in T>
    {
        void OnCompleted();
        void OnError(Exception error);
        void OnNext(T value);
    }
}
#endif

我想使用标准接口,以便 .NET 4.0 用户能够以我还没有想到的很酷的方式进行集成。所以我不想只是重复这个概念并松散与其他即将出现的IObservable&lt;T&gt; 用法的集成。

我看到的危险是,如果我的库的 .NET 3.5 版本在 .NET 4.0 中使用,则可能会出现类型冲突。不过,理想情况下,使用 v4.0 的人会使用 4.0 版本的库。

在使用这种方法时我还应该注意什么其他事项?

2) 或者,我已经考虑在我的代码中这样做(这是我倾向于的方向)并且想知道人们对为什么这是一个坏主意的想法:

#if !NET40
namespace Foo
{
    public interface IObserverProxy<in T>
    {
        void OnCompleted();
        void OnError(Exception error);
        void OnNext(T value);
    }
}
#endif

稍后我想在哪里使用它:

#if NET40
using IObserverBar=System.IObserver<Bar>;
#else
using IObserverBar=Foo.IObserverProxy<Bar>;
#endif

有什么想法吗?

【问题讨论】:

    标签: system.reactive


    【解决方案1】:

    由于 C# 扩展方法不能很好地与外部别名一起使用,我建议您不要将接口放在 System 命名空间中,因为它会破坏同时使用 Rx 和您的库的人,我会将接口放在Foo 命名空间。想要使用你的库和 Rx 的人总是可以像这样构建一个扩展方法:

    static System.IObservable<T> ToSystemObservable<T>(this Foo.IObservable<T> source)
    

    由于这个原因,Rx 中的 Observable 接口也已移至单独的 dll System.Observable.dll,我强烈建议您重新考虑使用这些接口。此 dll 不会从 Rx 构建版本到 Rx 构建版本,因此不应该有版本问题。这样,任何使用您的库的人都可以使用他们想要对您的可观察对象进行查询的任何(最近的)Rx 版本。

    【讨论】:

    • 这些都是好点。我绝对不会把它放在 System 命名空间中,但很好奇如果我这样做了会发生什么。如果不需要,我仍然希望不包含外部 DLL,因为这不是我的库的核心概念,但很高兴知道他们已经隔离了这方面。谢谢!
    猜你喜欢
    • 1970-01-01
    • 2011-03-13
    • 2011-04-29
    • 2011-02-18
    • 2014-11-30
    • 1970-01-01
    • 2011-06-24
    相关资源
    最近更新 更多