1

フレームワークの依存関係に関連する質問がいくつかあります。一般的に、ベスト コーディング プラクティスでは、名前空間をフレームワーク固有のコードで乱雑にしないようにします。たとえば、Spring の場合、すべての依存関係を構成ファイルで維持する必要があり、アプリケーション コードに Spring 固有のコードはありません (これが、Spring アノテーションよりも Spring 構成 xml ファイルを好む理由の 1 つです)。puremvc の場合と同様に、puremvc コードを mxml に混在させないことが常に望ましいため、ビューはどのフレームワークでも機能します。しかし、私の質問は

  1. 他のフレームワークを置き換えずにコードから spring または puremvc を削除すると、いくつかの Bean (Spring の場合) またはいくつかの真に再利用可能なビュー (puremvc の場合) になります。しかし、フレームワーク固有のAPIを使用せずにフレームワークに間接的に依存しているため、Beanまたはビューを接着するには大量のコーディング作業が必要です。

  2. スプリングをピココンテナのような他の DI フレームワークに置き換えると、かなりの量または手直しが必要になります。これも、フレームワークへの間接的な依存につながります。

では、アプリケーションの名前空間をフレームワーク固有の api で乱雑にするのはなぜ悪いのでしょうか? フレームワーク固有の API をコーディングできます (コーディング作業が大幅に軽減される場合)。

私によると、アプリケーションの名前空間をフレームワーク固有の API と混在させないだけでは、アプリケーションが他のフレームワークに移植可能になるわけではありません。既存の適切に設計された Struts アプリケーションを spring mvc で移行する場合、およびそのために必要な労力を考えてみてください。

他の読者からの意見を期待しています。

4

2 に答える 2

2

懸念事項を分離しておくことは、ソフトウェア設計の基本原則だと思います。MVC のモデル レイヤーにコードを表示したくないのと同じように、アプリケーション コードにコンテナー固有のコードは必要ありません。

多くの場合、ツール用のコードを作成する必要があることは間違いありません。たとえば、カスタムタイプが必要な場合は休止状態固有のコードを記述し、カスタムアプリケーションコンテキストが必要な場合はSpring固有のコードを記述します。それは何も悪いことではありません。重要なのは、アプリケーションの他の機能スライスから分離しておくことです。

これは、「即時」の移植性を保証するものではありません。それが促進するのは、「簡単に」コードを別の場所に移植できることです。この文脈での「簡単に」は、仕事がないという意味ではありません。むしろ、Pico に移行することを決めたからといって、Spring 固有のものを削除し始める必要がないことを意味します。つまり、中核となるビジネス機能は損なわれず、移動を決定したときに構成またはコンテナー固有の依存関係を移植するだけで済みます。

于 2010-12-09T20:34:55.423 に答える
1

ソフトウェア開発におけるすべての抽象化と同様に、フレームワークを使用しているときは、単に「問題」を移動しているだけです。フレームワークが特定の処理を行うため、アプリケーションの他の部分はその処理方法を知る必要がありません。たとえば、依存性注入を使用する場合、注入されるクラスは依存性を作成する方法を知る必要がなく、依存性注入フレームワークによって処理されます。

しかし、これは知識/責任が移動したことを意味するだけです。それは決して、決して、再移動されません。もちろん、コードは暗黙的にそのフレームワークに依存しています。ただし、フレームワーク関連のコードを 1 つの場所に移動する場合、おそらくいくつかのインターフェイスを導入してそれをラップする場合でも、コードの残りの部分が特定のフレームワークではなく、インターフェイス、クラス、またはフレームワークに依存するようにすることができます。

たとえば、 Resolveメソッドのみを使用して、 IIocContainerインターフェイスをコードに導入しました。このインターフェイスを実装するオブジェクトは、特定の Ioc/DI フレームワークを呼び出す方法の知識を保持します。しかし、この知識はこの 1 つのオブジェクトにのみあります。私のアプリケーションの残りの部分 (必要な場合) は、 IIocContainerインターフェイスについてのみ知っているため、特定のフレームワークに依存しません。フレームワークを変更する場合、参照と構成を変更するだけで済み (XML にあり、コードにはまったく影響しない可能性があります)、このコンテナーにIIocContainerを実装する別のオブジェクトを使用します。

コードの構造/アーキテクチャに直接影響するフレームワークについて話している場合 (たとえば、基本クラス、命名規則などによって)、これは、特定のフレームワークを抽象化することがはるかに難しくなることを意味します。できますが、基本的に行うことは、別のフレームワークを中心に独自のフレームワークを作成することです。最終的に構造フレームワークを切り替える場合、そのフレームワークを直接書き直すか、フレームワークを抽象化することによって、常に多くの作業が必要になるため、賢明ではありません。

簡単に言えば、フレームワークを使用して「やらなければならない多くの構造的な配管」の問題をそのフレームワークに移動している場合（フレームワークに配管を処理させます）、フレームワークを切り替えると、 「やらなければならない多くの構造的な配管」の問題をすぐに取り戻すつもりです。:-)

于 2010-12-13T03:28:21.667 に答える