ベースアプリケーションフレームワークに関して、他のショップが何をしているのか気になりましたか? 私は、アプリケーション フレームワークを、そこから構築されたアプリケーションの品質を向上させる追加機能または拡張機能を提供できるものと考えています。
Spring (または Spring.NET) など、すぐに使用できるさまざまなフレームワークがあります。これらの最大の問題は、それらがアラカルトではないことです。基本的に、それらには多すぎる機能があり、その機能のすべての部分が利用可能な最良の実装でない限り、これらのタスクを達成するために複数のフレームワークのパッチワークを使用することになり、肥大化と混乱を引き起こす可能性があります. 私の意見では、これは無料の商用システムにも当てはまります。
もちろん、書くことは大部分が車輪の再発明です。ただし、最もカスタマイズ可能なオプションを提供するため、メリットがないわけではないと思います。ただし、いくつかのものは開発するには大きすぎます。この場合、開発の初期費用を負担することを躊躇しているため、実装が不十分であるか、まったく実装されていないように見えます。
アプリケーション フレームワークの個々の部分に対処するさまざまなオープン ソース プロジェクトも存在します。これらは、さまざまなソースからの包括的なフレームワークを構成するのに役立つように、採用または同化することができます (明らかにライセンス契約に依存します)。
私たちは、企業全体のアプリケーションにおけるより大きな懸念事項のいくつかを調べることで状況に取り組み、有効な分野横断的な懸念事項と繰り返し発生する実装の問題のリストを作成しました。最終的に、部分的にオープン ソースであり、部分的に既存のオープン ソース オプションに基づいており、部分的にカスタム開発されたハイブリッド ソリューションを思いつきました。
私たちのフレームワークにあるもののいくつかの例:
- 例外およびイベント ログ プロバイダー。すべてのアプリケーションが最小限のコーディング作業で同じ方法で例外とイベントをログに記録できる、シンプルで統一された手段。そのまま使用して、SQL Server、テキスト ファイル、イベント ビューアーなどにログを記録できます。他のソースにログを記録するための拡張ポイントも含まれています。
- 変数割り当ての強制。JUnit に着想を得た構文を使用して、オブジェクト タイプに基づいて拡張メソッドを公開するジェネリック クラス。たとえば、myObject が null でないかどうかを判断するには、単純な Enforce.That(myObject).IsNotNull(); を実行できます。または、単純な Enforce.That(myObject).IsOfType(typeof(Hashtable)); を実行して、特定のタイプであるかどうかを判断します。適用が失敗すると、適切な例外が発生し、コードの量が削減され、実装の一貫性が確保されます。
- 単体テスト ヘルパー。クラスとそのプロパティを自動的にテストできるリフレクションに基づく一連のクラス。(CodePlex のAutomatic Class Testerに触発された) しかし、ゼロから書かれています。従来はテストが困難または時間がかかっていたものの単体テストの作成を簡素化するのに役立ちます。
他の機能もそのまま採用しています。たとえば、AOP にはPostSharp、モッキングにはmoq 、DI にはautofaqを使用しています。
他の人が何をしたのか、満足のいくツールが見つからなかったフレームワークがどのような問題に対処しているのか、疑問に思っていますか? 私たちの経験としては、新しいフレームワークのメリットを確実に享受しており、採用したアプローチに満足しています。