9

Ruby on Rails に mvc フレームワークを使用したアプリケーションがあります。今のところ、コントローラーに API 呼び出しがありますが、これは適切な場所ではないと思います。すべての API 呼び出しをどのようなファイルに入れる必要がありますか? ありがとう

def getDetails(id)
 api_response = HTTParty.get(base_uri, :query => {:DID => id, :DeveloperKey => devKey})
 @json_hash = api_response.parsed_response
 return @json_hash
end
4

3 に答える 3

14

外部サービス (サードパーティ) への API 呼び出しは、(理論上) 誰でもサービスを利用できるため、アプリに固有のものではありません。これらの種類の機能は、lib/アプリ固有ではないため、ディレクトリに配置されることを理解しています。理想的には、自分のプロジェクトからコードを引き出して、別のプロジェクトlibの他の人のコードにドロップしても、lib/問題なく機能します。

コールを に入れますlib/。必要に応じて、コントローラーで返されたデータからモデルを作成できます。

次のようになります。

アプリ/コントローラー/

class YourController < ApplicationController

  def getDetails
   # keep in mind, api call may fail so you may want surround this with a begin/rescue
   api_response = YourApiCall.new.get_details(params[:id])
   # perhaps create a model
   @model = SomeModel.new(fname: api_response[:first_name], lname: api_response[:last_name])
    # etc...
  end
end

ライブラリ/

require 'HTTParty'

Class YourApiCall
  def get_details(id)
    HTTParty.get(base_uri, :query => {:DID => id, :DeveloperKey => devKey})
    @json_hash = api_response.parsed_response
    return @json_hash
  end
end
于 2013-03-04T16:40:47.620 に答える
9

これには非常に遅れましたが、2p/2c を追加すると思いました。

私は、リクエスト タイプとパラメーターに基づいてプログラム フロー コードとして大まかに定義するコントローラー コード以外は、コントローラーをクリーンな状態に保つようにしています。たとえば、リクエスト タイプに適したテンプレートを選択したり、ユーザーがログインしているかどうかに基づいて呼び出す正しいメソッドを選択したりします。

応答の計算に関しては、モデルを操作してインスタンス パラメーターを設定する大量のコードをコントローラーに散らかすのは好きではありません。これはテストが難しく、再利用するのはさらに困難です。別のオブジェクトを延期し、単一の値オブジェクトをテンプレートに返すことを好みます。

場合によっては、モデルに従うこともできます。単純なルックアップで、単一のモデルまたはモデルの配列をテンプレートに送信しているだけかもしれません。

適切な値または値オブジェクトを返すために、モデルに便利なメソッドを実装した可能性があります。

ただし、モデルを使用しないことや、複数のモデルを使用すること、または実際にモデルを散らかすべきではないと感じることがあります。この場合、コントローラもモデルもコードの適切な場所ではありません。

lib ディレクトリも適切ではありません。私は lib ディレクトリを、まだ gem に変換したことがないコードを含む場所として扱う傾向があります。私が書いているコードがアプリケーションのコンテキストでしか意味をなさない場合、それはうまくいきません。

そこで、サービス オブジェクトに目を向けます。「app」フォルダーの下に「services」フォルダーがあります。このフォルダーには、サイトの動作の単一のチャンクをカプセル化する小さな機能クラスが含まれています。(または、コントローラーに単純なインターフェースを提供するために、他のいくつかのサービスを調整することもあります。)

これにより、コントローラーとモデルをスリム化でき、API に接続する必要があるコードを配置するのに最適な場所になります。

さらに一歩進めたい場合は、API 自体をラッパー クラス (またはクラスのセット) でラップし、それらを lib ディレクトリに保持することができます (後で gem に変換するため)。次に、サービス オブジェクトは、(コントローラーから渡された) 適切な値で API ラッパーを呼び出すタスクを実行し、テンプレートがクリーンに問い合わせることができる何かで応答します。

もちろん、これをさらに進めて、さらにレイヤーを追加することもできます。たとえば、プレゼンテーション レイヤーは、サービス オブジェクト (一般的な値を提供する) と特定のビューのフォーマット データの間に配置できます。(たとえば、Web ページと RSS フィードの両方を提供する必要があり、それらには異なる日付形式が必要な場合があります。)

しかし、あなたはその考えを理解します。

于 2015-12-07T16:09:48.057 に答える
5

私のコーディング スタイル (および MVC の理解) により、外部呼び出しは「テーブルレス」モデルに配置されます。RailsCasts 193ではこの概念について少し説明されており、Rails 4 ではあまり扱いにくい構文がサポートされています。これらのメソッドをコントローラーに移動しても機能しますが、アプリが大きくなるにつれて問題が発生する可能性があります。

外部 API 呼び出しに関するもう 1 つの考慮事項は、実際にそれらをデータベースに格納することです。これは、その時点で確実にモデルに含まれている必要があるため、(私にとって)これらが実際にモデルに含まれている必要があることがより明確になります。

于 2013-03-04T16:24:56.763 に答える