1

以前のバージョンのフレームワークもサポートする必要があるライブラリに.NET4.0インターフェイスIObserverを使用したいと思います。フレームワークのバージョンごとにビルドできる条件付きコンパイルがすでにあります。

Rx Extensionsのバージョンを使用したくないのはIObserver<T>、それ以外の場合はスタンドアロンアセンブリに不要な依存関係が追加されるためです。

私が検討しているのは、このコードブロックをライブラリに追加することです。皆さんへの私の質問は、次のとおりです。

1）これは悪い考えだと思いますが、「なぜ」と正確に理解しようとしています。

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

標準のインターフェイスを使用して、.NET4.0ユーザーがまだ考えもしなかったクールな方法で統合できるようにしたいと思います。したがって、概念を複製して、他の今後の使用法との統合を失いたくありませんIObservable<T>。

私が目にする危険は、ライブラリの.NET3.5ビルドが.NET4.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

何かご意見は？

4

1 に答える 1

3

C＃拡張メソッドはexternエイリアシングと一緒にうまく機能しないため、インターフェイスを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の任意の（最近の）ビルドを使用できます。

于 2010-07-21T23:49:23.890 に答える