ロギング、IoC/DI などの一般的なインターフェイス(ただし実装はありません) を備えたオープン ソース アセンブリが必要です。これが存在する場合、あまり多くのグルー コードを記述することなく、ビットとピースを組み合わせて組み合わせることがより簡単になります。
例: これが存在する場合、たとえば asp.net mvc アプリケーションを作成し、ORM、ログ、および IoC フレームワークを追加できます。次に、コントローラーとモデルを使用してサードパーティのアセンブリへの参照をドロップすることができ、それらは一緒にうまく機能します。独自のインターフェイスを作成する場合、これらのそれぞれを変更する必要があります。変更するのではなく、1.ドロップイン、2.構成、3.使用したい! それほど難しくはありません。
このようなことを聞いたり、使用したり、書いたりしたことがありますか?
Common Infrastructure Libraries for .NETと呼ばれるプロジェクトがあり、これはあなたが求めているものに似ています。ただし、現時点では、ロギングの抽象化のみが利用可能です。
Markが推奨しているように、独自のインターフェースを定義することは悪いことではありません。そうすれば、インターフェースはアプリケーションやユースケースにとって意味のあるものになります。後で、ある概念/コンポーネントのオープンソースの汎用抽象化を見つけた場合は、コードをリファクタリングして使用するか、単に既存のインターフェイスに適合させることができます。
理論的には一般的な抽象化は良い考えですが、現在、多くの「一般的なもの」については、受け入れられている「一般的なアプローチ」はありません。
そのようなアセンブリは存在しないと思います。運が良ければ、使用することにしたライブラリは、IWindsorContainerインターフェイスを実装するWindsorコンテナなど、実装する独自のインターフェイスを定義します。
ただし、別のDIコンテナを使用する場合、たとえば、StructureMapはIWindsorContainerを実装していないため、そのインターフェイスを再利用することはできません。
いずれにせよ、そのような図書館のポイントが何であるかはわかりません。数分でインターフェースを書くことができます。開発に時間がかかるのはインターフェースではなく、実装です。
独自のアプリケーションで必要なインターフェイスを定義します。その場合、そのアプリケーションに必要なプロパティとメソッドを正確に定義するだけでよいため、よりターゲットが絞られ、冗長性が低くなります。
IoC フレームワークは、CommonServiceLocator を使用して分離できます: http://www.codeplex.com/CommonServiceLocator