新しい .net 3.5 winform プロジェクトでの CAB の使用を評価中です。
「CAB 準拠」であることが知られているInfragistics ツールセットを使用する予定です。
CAB には、基本的なドッキング/ログインなどのコードをコーディングする代わりに、自分のビジネスに集中できるという直接的な利点がありますが、同じレベルの機能を自分で非常に迅速に実現できると感じています (柔軟性/反応性のボーナスが追加されています)。コードを「所有」している場合)。
Microsoft の CAB を使用しているユーザーからのフィードバックを求めています。
私は数年前にCABを使用した経験がありましたが、私の結論は、CABは複雑すぎて、学習曲線が急だったということでした。そのため、それが提供するメリットは、それに慣れるだけの価値はありませんでした。しかし、私の言葉を信じないで、彼らのラボのいくつかをフォローしてみて、あなたがどう思うか見てみましょう。
Jeremy Millerは、独自のCABの構築に関する一連の優れたブログ投稿を作成しました。
そこから必要なものを取り出すことができるので、これらは一見の価値があります。
私のアドバイスは、事前にフレームワークを構築するのではなく、プロジェクトに取り掛かることです。プロジェクトが発展するにつれて、コードを基本クラスにリファクタリングし、アプリケーションからフレームワークを効果的に収集する機会を見つける必要があります。
そうすることで、ニーズに合ったフレームワークが完成し、開発チームの全員が理解できるようになります。何をするにしても、前もってフレームワークを構築しないでください-破滅への道があります:-)
いくつかのプロジェクトで CAB+SCSF を使用しました。学習曲線は確かに急勾配です。おそらく、最初の 1 か月後には速度に慣れているでしょう。その他の短所:
長所：
業界のアーキテクチャ設計パターンのベスト プラクティスに従います。
長期的に CAB-SCSF を使用すると、バグが減り、コードの保守が容易になります。あなたのプロジェクトが学習曲線の最初のヒットに余裕があるなら、私は間違いなくそれをお勧めします.
CAB フレームワーク上にエンタープライズ アプリケーションを構築しましたが、ニーズに合わせて多くの部分を変更しました。
その経験から、非常に柔軟なモジュラー アーキテクチャが必要で、UI、ビジネス ロジック、データ レイヤーの開発が明確に分かれている場合は、CAB の方が適していると言えます。
CAB には多くのコードが生成されるという欠点があり、開発者が単純な結果を得るために複雑なメカニズムを使用するようになることがあります (イベント パブリケーション/サブスクリプション モデルの過剰使用、最も単純な UI の mvp パターンなど)。
これについての紹介が必要な場合は、 http://richnewman.wordpress.com/intro-to-cab-toc/に Rich Newman による優れたシリーズがあります。
依存性注入/制御の反転のみを利用したい場合は、Managed Extensibility Framework ( http://mef.codeplex.com/ ) が非常に優れた軽量の代替手段になります。
私は CAB を実際に使用したことはありませんが、ソース コードが付属しているため、アプリケーション ブロックによって提供されない追加の柔軟性が必要な場合は、正確なニーズに合わせて微調整することができます。