Ember オブジェクトと Ember データのオブジェクトの違いは何ですか? サーバー上にデータがある場合は Ember Data モデルを使用する必要があることはわかっていますが、いつ、どこでどちらを使用する必要がありますか?
1 に答える
注: これはかなり長く、偏見があり、この問題に関する私自身の意見を表しています。答えにならないかもしれません。
この型Object
は、Ember で最も「単純な」オブジェクト型と呼べるものです。計算されたプロパティやオブザーバブルなど、最新のアプリケーションで使用する可能性が高い最も重要な機能を備えています。また、ランタイムと連携して、バインディングやフィルタリングなども可能です。私はそれを汎用オブジェクトと呼びます。これは、拡張して他のタイプを作成でき、ミックスインと組み合わせて使用法をさらに強化することもできます。DS.Model
機能の数は限られていますが、優れた機能を備えていますが、その機能を知っているという理由だけで、バックエンドフレンドリーとは言えません。
Ember-Dataは、(ほとんどの場合) RESTful 環境でバックエンド データを操作するときに意味のある機能を提供するためにDS.Model
、機能を大幅に拡張しています。Object
ORM でサポートされているオブジェクト (.NET の EntityFramework や Ruby の ActiveRecord など) と同じように、一連の機能を提供するため、そのタイプ ( ) のオブジェクトをデータ ストア ( )DS.Model
を通じて管理できます。状態管理 ( 、、、など)、ストア (およびその後のバックエンド API) でオブジェクトを作成する機能、関係/関連付けなどをDS.Store
許可します。Object
isDirty
isNew
isError
isNew
commit
rollback
Ember-Data をまったく使用している場合は、 type を使用する必要があります。Model
これは、(ストアで使用することを意図しており、) サイドローディング、関連付け、複数形、および AJAX 要求/応答ワークフロー全体でモデル タイプを使用するためです。Model
実際、 a に裏打ちされた aを使用する利点の 1 つは、Store
まさにこれです。正しい RESTful リソースへの AJAX 要求を独自に構築し、応答を管理し、JSON ペイロードをデータが要求/処理/具体化されている間にモデルを使用できるという約束を与えながら、正しいタイプのオブジェクト(これが起こっている間にビュー/ルートを移行することができます)。
また、ストアでサポートされているオブジェクト自体 (例: ) 内に多くの便利な機能を提供record.deleteRecord(); store.commit()
し、最終的には生産性が向上し、アプリケーションをより迅速に構築できます。
そうは言っても、多くの開発者は通常、人々がテクノマジックと呼ぶものに頼ることを好まないか、快適に感じていないため、このアプローチには批判があります。言い換えれば、内部で起こっていることを 100% 制御できていないと感じているため、使用したくありません。私の個人的な意見では、これらの人々がどこから来ているかを見ることができると同時に、Ember-Data は私が生産性を高めるのに何の役にも立たないと信じています。私は特定の慣習に従っており、それに満足しています。
に戻ると、Object
Ember-Data を使用していない場合は、Object
型をモデルとして使用する必要があります。これは、これらのタスクをすべて手動で行う必要があることを意味します (通常は大したことではありません)。そのため、AJAX 要求を手動で作成し、応答を処理し、応答データをオブジェクトに読み込み、クライアント アプリと API の間のすべての通信ワークフローを基本的に維持する必要があります。利点は、 Robin Ward がここで説明しているように、100% コントロールできることですが、もう少し努力する必要があります。ルーティング API と、Ember を構成する優れた機能のほとんどを引き続き使用できます。
したがって、これらの各タイプをいつどこで使用するかという問題は、バックエンドにどのようなアーキテクチャがあり、それに関してどの程度の柔軟性があるかによって異なります。
これは誰にとっても明確な答えが得られるものではありませんが、Ember-Data を使用することの実行可能性を評価するいくつかの質問に答えることで対処できます (長期的に考えてください)。
- 私の API は、Ember 規約で定義されているのと同じ形式で JSON を返しますか?
- それが部分的にしか当てはまらない場合、私のチームと私は単純にモデル ベースでマッピングを定義して、すべてを規則に準拠させることができますか?
- そうでない場合、これらの規則に準拠するようにバックエンド API を変更できますか?
- そうでない場合、バックエンド テクノロジに固有のアダプタはどこにありますか?
- 見つかりません。独自のアダプターを作成することは可能でしょうか?
これらの質問に答えた後、開発の反復とライフサイクルを考慮してください。長期的には、どちらのアプローチでもそれを維持するには何が必要かを考えてください。また、アーキテクチャや開発戦略を決定する際に、コミュニティ内の他の 人々がどのような道をたどったかも考慮してください。
最終的には、これらのオブジェクトが機能に関して何をもたらし、アプリケーションを構築するためにそれらが必要かどうかを理解する必要があります。私見ですが、Ember-Data はほとんどの場合に適した方法であり、パッケージの一部として Ember-Data が含まれる可能性が高い Ember 1.0 最終版 (おそらく RC3、その後) に近づくにつれて改善されるだけです。
これが役立つことを願っています