3

外部APIをラップするための軽量のRubyコードを作成しました。

api = ExternalAPI.new
api.expensive_operation(object)

正常に動作します。ただし、APIは高価なので、必要がない限り呼び出したくありません。これが、API呼び出しをローカルキャッシュでラップする高レベルのAPIを作成している理由です。APIがどのようにキャッシュされるかについての詳細をアプリケーションが心配する必要はありません。（キャッシュは、メモリ、ディスク、そろばん、さらにはハトによっても実行できます。アプリケーションの問題ではありません。）

これが私が現在検討していることです：

ラッパー=ExternalAPIWrapper.new
wrapper.expensive_operation（object）

名前が気に入らないExternalAPIWrapper。これは一般的であり、ラッパーの目的を伝えません。特に、最初にローカルキャッシュをチェックし、必要な場合にのみ低レベルAPIにヒットすることを示すものではありません。

この出発点を改善する答えを探しています。これが私が探しているものです：

  1. 高レベルのクラスのより良い名前
  2. より良いスタイルのAPI
  3. 役立つ可能性のあるデザインパターン
  4. （おそらくロングショット...）API呼び出しをラップしてキャッシュするRuby gem
4

3 に答える 3

3

＃1の場合、頭に浮かぶ名前はCachedExternalAPI:)「より良いスタイルのAPI」が何を意味するのかわかりません。

＃3/4について：この種のキャッシングを行うRubyGemはわかりませんが、キャッシュされたAPIを「メタプログラミング」方式で実装し、キャッシュされたAPI呼び出しのメソッドを自動的に生成します。

class CachedExternalAPI
  @cache = { }

  class << self

    [:foo, :bar, :baz].each do |m|
      define_method m do
        return (puts "Totally cached!"; @cache[m]) if not @cache[m].nil?
        puts "Not cached :("
        @cache[m] = 42
      end
    end

  end
end

CachedExternalAPI.foo()
CachedExternalAPI.foo()

CachedExternalAPI.bar()
CachedExternalAPI.bar()

どちらが得られます

キャッシュされていません:(
完全にキャッシュされています！キャッシュされ
ていません:(
完全にキャッシュされています！

もちろん、これはすべてのAPI呼び出しのキャッシュメカニズムが同じであることを前提としています。ただし、APIがそのようにキャッシュ可能である場合は、キャッシュされたAPIラッパーをかなりDRYに保つことができます。

于 2012-07-18T19:38:48.467 に答える
2

私の友人であるRobは、APICacheを見つけました。

APICache（別名api_cache）

APICacheを使用すると、任意のAPIクライアントライブラリを堅牢なキャッシュレイヤーで簡単にラップできます。キャッシュ（明らかに）をサポートし、古いデータを提供し、API呼び出しの数を制限します。面倒なURLをキャッシュするだけの場合は、便利な構文もあります。

APICacheは、次のような複数のキャッシュ戦略をサポートしています。

  • シンプルなメモリ内キャッシュ
  • 「Key-Valueストアへの統合インターフェース」であるMonetaを介したさまざまなバックエンド
  • Dalliを介してMemcachedされ、Dalíの記憶の固執にちなんで名付けられました
于 2012-07-18T22:05:52.963 に答える
0

詳細が少なすぎて正確に何が必要かを知ることはできませんが、キャッシュバックエンドの変更を検討するときに、抽象化と実装を本質的に切り離そうとしているため、すぐにブリッジパターンを考えました。

于 2012-07-18T20:00:49.610 に答える