少なくとも表面上は、ember アプリの構築に関する非常に基本的なアーキテクチャ上の問題であると思われます。
コントローラーの種類は?
先月かそこらで、人々が Ember.Controller、Ember.ArrayController、Ember.ObjectController、および Ember.ArrayProxy を通じてコントローラーを実装しているのを見てきました。ArrayController と ArrayProxy を削除します (それらは同一であるため)。各タイプの一般的な使用例は何ですか?
これまでのところ、私はそれを集めることができました:
- 制御するビュー内にn 個の要素がある場合は、ArrayControllers/Proxy を使用する必要があります。
- ビューが単一のオブジェクトで状態を維持するのに十分なほど単純である場合、またはモデルのオブジェクトの単一のインスタンスである場合は、ObjectControllers を使用する必要があります。
- コントローラ --- ? わかりません。
コントローラ タイプ間の基本的な違いは何ですか? いつ、どのユースケースを使用するかについての具体的な情報はないようです。API ドキュメントは、それらのそれぞれの核心を伝えるのは得意ですが、それぞれをいつ使用するかはわかりません。
View と Controller の関係が不可解な場合がある
View が Routes ConnectOutlets 関数呼び出しを介して接続されると、コントローラーとビューの間で正確に何が起こるのでしょうか?
イベントはビュー自体に関連付けられていますか (そのようです)。もしそうなら、一体どこでコントローラー シングルトンとやり取りして、そのプロパティで CRUD らしいことを実行しますか? this.get('controllerName') はそのトリックを実行していないようで、そこにあるほぼすべての投稿、チュートリアル、またはコード サンプルはこれを別の方法で行っています。
そうでないモデル
Ember Data は、データを処理して同期を維持する際の厄介な部分のいくつかを解決するのに役立つように見えますが、より大きな観点から見ると、「MVC」の概念では、ember は実際にはモデルを持っていないようです。いずれかの種類。特定のものからサブクラス化されて追跡されるオブジェクトです....どこか?何とかして?魔法の?
@trek は、Ember.Object が ajax のデータとクライアントでの処理状態を問題なく管理できることで十分でしたが、todomvc.com の ember アプリのようなものを見ると、実装が完全に異なる localStorage パラダイムを使用し、すべてのものとは異なります。私は見てきた。
ここでMVC方程式の「モデル」部分をどのように正確に行う必要がありますか?
景色を見ると子供を殺したくなる
ユーザーにマークアップを表示するという観点から、「ビュー」を構築する方法は多数あるようです。
- サブビュー / チャイルドビューを使用した ContainerView
- ネストされたアウトレット
- ハンドルバー テンプレート + アウトレット
- コントローラーで #each foo を使用する
- リテラルによる注入 (
template: Ember.Handlebars.compile('<h1>foo</h1>')
など)
それを念頭に置いて、ember でモジュラー UI コンポーネントを構築する「適切な」方法は何ですか? これは何よりも、私にとってこのフレームワークを採用する上での大きな問題点です。
Ember がウェブ上でアプリケーション開発を行っている方向性が気に入っています。概念は単純に見えますが、冗長性はObjective-Cのそれです(系統を考えると理にかなっています)が、実際にアプリケーションに取り組んでいるよりも、神の忌まわしいフレームワークと戦っているように感じることを神に誓います。構文の冗長さと、API ドキュメント以外の構造化ドキュメントの欠如 (現実を直視すると、300k の JavaScript は、いくつかのブレークポイントをスローして問題をデバッグしようとするためのかなりの量のコードです)。
皆さんが直面している課題は理解していますが、これが少なくとも 1 分間立ち止まって、他のフレームワークで作業している次期開発者 (あるいは、MVC フレームワーク内で作業していたとしても) の作業をどのように楽にすることができるかを考えさせてくれることを願っています。 、rails、django、backbone、または angular など) を使用して、「これが ember の使用方法だと考えています」と言うことができます。
独断的なソフトウェア設計の決定をいくつか取り、それをコミュニティに適用します。あなたがそうしてくれたら、私たちはあなたのチアリーダーになるだけです、約束します.