3

Java/Jersey で記述された Web サービス レイヤーがあり、JSON を提供します。

アプリケーションのフロントエンドには、Rails を使用したいと考えています。

モデルを構築するにはどうすればよいですか?

私はこのようなことをすべきですか?

response = api_client.get_user(123)

User user = User.new(response)

JSONをRubyオブジェクトにマッピングするための最良のアプローチは何ですか?

どのようなオプションがありますか? これは重要な部分であるため、パフォーマンスが重要な要素であるため、選択肢を知りたいです。これは、JSON を Ruby オブジェクトにマッピングし、Ruby オブジェクト => JSON に移行することに加えて、アプリケーションでよく発生します。

私はまだ検証を利用することができますか? それとも、フロントエンドとサービス層で検証が重複しているので意味がありませんか?

4

1 に答える 1

2

Rails のモデルはデータベース操作を行う必要はなく、通常のクラスです。通常、ActiveRecord::Base からサブクラス化すると、ActiveRecord の魔法が吹き込まれます。

属性を持つモデルを提供するVirtusなどの gem を使用できます。検証のために、 Vanguardを使用できます。データベースに近いものを必要としActiveRecord、Rails 3 以降を実行している場合はActiveModel、モデルに含めて、属性と検証を取得し、それらをフォームで機能させることもできます。詳細については、 Yehuda Katz の投稿を参照してください。

あなたの場合、それはあなたが消費するデータに依存します。たとえば、すべてのデータソースの基本的な形式が同じである場合、独自の基本クラスを作成して、個々のクラス間で共有するすべてのロジックを保持できます (継承)。

いくつかの異なるタイプのデータが入ってくる場合は、モジュールを作成して、さまざまなタイプの動作をカプセル化し、必要なモデルを適切なクラス (構成) に含めることができます。

ただし、一般的には、リモート API のリソースごとに 1 つのクラスを作成し、ドメイン ロジックに 1 対 1 でマッピングすることをお勧めします。これはさまざまな方法で行うことができますが、ActiveRecord で使用されるメソッド命名に従うことをお勧めします。これは、クラス構造を構築しながら ActiveRecord を学習し、API が ActiveRecords のように見えて動作する場合、後で他の Rails 開発者に役立つからです。

オブジェクトに対して何ができるようにしたいかという観点から考えてみてください (ここで TDD の出番です)。Model.allコレクション、特定の要素を取得したりModel.find(identifier)、変更された要素をリモート サービスにプッシュしupdated_model.saveたりできます。

これらのメソッドの内部にある実際のロジックは、リモート サービスによって異なります。しかし、おそらく、各モデル クラスにそのリソース エンドポイントへの URL を保持させ、モデル内のロジックを断固として保持したいと考えるでしょう。したがって、代わりに:

response = api_client.get_user(123)

User user = User.new(response)

あなたは〜をします

class User
  ...
  def find id
    @api_client.get_user(id)
  end
  ...
end

User.find(123)

またはそれ以上の可能性

class ApiClient
  ...
  protected

  def self.uri resource_uri
    @uri = resource_uri
  end

  def get id
    # basically whatever code you envisioned for api_client.get_user
  end
  ...
end

class User < ApiClient
  uri 'http://path.to.remote/resource.json'
  ...
  def find id
    get(id)
  end
  ...
end

User.find(123)

基本原則: すべての共有ロジックをクラス (ApiClient) に集めます。リソース (ユーザー) ごとにサブクラス化します。モデル内のすべてのロジックを保持します。システムの他の部分は、それが DB を利用したアプリなのか、それとも外部 REST API を使用しているかを知る必要はありません。何よりも、統合ロジックを基本クラスに完全に保持できる場合に最適です。そうすれば、外部データソースが変更された場合に更新する場所が 1 つだけになります。

逆に言えば、Rails にはオブジェクトを JSON に変換する優れた方法がいくつかあります。to_json メソッドから、RABL などの gem を使用して JSON オブジェクトの実際のビューを取得する方法まで。

ActiveRecord モジュールの一部を使用して検証を取得できます。Rails 4 の時点で、これは ActiveModel と呼ばれるモジュールですが、Rails 3 でも実行できます。また、 RailsCastなど、オンラインでいくつかのチュートリアルがあります。

ネットワークが遅い場合に、リモート サービスを呼び出すときに発生する可能性があることを除いて、パフォーマンスは問題になりません。その一部はおそらくキャッシングで解決できますが(詳細については、私による別の回答を参照してください)、使用しているデータにも依存します。

あなたが正しい軌道に乗ったことを願っています。また、この種の構造を設計する方法についてより完全な基礎が必要な場合は、そのテーマに関する本を手に入れる必要があります

于 2013-01-09T12:07:13.027 に答える