3

多くの人が、ソフトウェアを設計する際に、サードパーティの API ライブラリへの呼び出しを中心に抽象化レイヤーを構築することをお勧めします。

したがって、これを正しく理解していれば、たとえば、jQuery を使用して Web アプリケーションを構築しているとします。jQuery を中心に抽象化レイヤーを構築し、残りのアプリケーション コードで抽象化 API と jQuery への直接呼び出しを使用する必要があります。

私の質問:

  1. これは有効な提案ですか？
  2. これにより、コードが複雑になることはありませんか?
  3. この規則に例外はありますか?
  4. これは、抽象化と再利用性の利点を無効にしないでしょうか?
  5. ソリューションが過度に設計されているように見える以上に、この層を持つことが理にかなっている程度はありますか?

前もって感謝します！

4

2 に答える 2

2

jQuery は非常に使いやすい API であり、「アプリケーション コード」レベルで非常に効果的に機能するように設計されています。抽象化は必要ありません。抽象化しても何のメリットもありません。

いくつかの「ライブラリ コンポーネント」またはその上に少量のライブラリ コードを構築する際に使用できる場合があります。これは、アプリ固有の UI コンポーネントとパターンを繰り返し使用するアプリケーション レベルの使用を除外するためです。

一般に、「すべてを抽象化する」というアドバイスはほとんど間違っているように聞こえます。抽象化は、交換可能にする必要がある、または交換可能にする可能性があるものに使用されます。必要のない抽象化は見当違いであり、有用ではなく、それ以外の場合はコストに他なりません。

jQuery はすでに抽象化レイヤーであるため、これを言った人は、彼らが話していることについて最初のことを知りません。

抽象化ではなく、より一般的な状況 (jQuery 以外のライブラリー) は、アプリケーション コードが動作するレベルより下の「ライブラリー実装」または SPI レベルで設計されていることです。

このような状況では、通常、独自のライブラリ コード/クラス (リーダー、ライター、ビルダー、およびその他の「タスク指向」クラスなど) を構築して、アプリケーション レベルの API を使用してアプリケーション コードで使用すると便利です。図書館までドライブ。繰り返しますが、これは抽象化ではありません。

実際に抽象化を使用するのに最も役立つ 3 つの場所は次のとおりです。

  1. データベースの移植性 -- Hibernate を使用し、DB 固有のジェネレーターに依存しない。と
  2. アプリケーション サーバー/OS ポータビリティ。Java とサーブレット/JSP は両方を提供します。
  3. 構成。たとえば、Spring のようなフレームワークを介して。
于 2013-11-05T03:36:06.713 に答える
1

かなり複雑な Web アプリケーション (UI、インタラクション、大量のデータ) を構築している場合、本質的に非常に優れた DOM 操作と AJAX ライブラリである jQuery だけでは、クライアント側を構築するために必要なツールは提供されません。保守可能な方法でコーディングします。

人々が話しているのを聞いたことのある抽象化は、Backbone、Knockout、Angular、Emberなど、ここ数年で登場し始めたさまざまなクライアント側フレームワークであり、そのほとんどが jQuery を使用 (または使用可能) していると思います。主に DOM 操作が得意です。

これらのフレームワークのいずれかが、車輪を再発明することなく、モジュール化された保守可能な方法でコードを構築するために必要なツールを提供します。Web アプリケーションが少しでも複雑な場合 (または時間の経過とともに複雑になる可能性がある場合) は、上記のいずれかを出発点として検討することを強くお勧めします。

于 2013-11-05T10:47:49.167 に答える