16

ember.jsアプリケーションを構築するためのベストプラクティスを理解しようとしています。トムデールからのこのスライド：

https://speakerdeck.com/u/tomdale/p/emberjs-more-than-meets-the-eye?slide=55

アプリケーションロジックを配分する方法についての簡潔な説明があります。ただし、これらのガイドラインに従おうとすると、いくつかの問題が見つかります。

  1. ルーターが大きくなりすぎています。プレゼンテーションによると、ルーターは「ビューからのイベントに応答します」が、これにより、ビューが数十ある場合に多くのコードが生成されます。
  2. 膨大な数のコントローラーがあります。Railsアプリケーションでは、CRUDアクションは通常同じコントローラーに存在しますが、残り火のアプリの場合、レコードを一覧表示するコントローラー、レコードを表示するコントローラー、レコードを作成するコントローラーなどが1つずつ必要なようです。

コントローラー、ビュー、ハンドルバーテンプレートの間に非常に多くのファイルがあり、それぞれに数行のコードしかないため、あまり乾燥しているとは感じません。

問題がガイドラインを誤って適用していることなのか、それともこれらのガイドラインが些細なアプリケーションでしか機能しないのかを判断しようとしています。

特にルーターの成長を管理する方法について、誰かアドバイスはありますか？

4

2 に答える 2

19

Emberがあまりにも多くのコントローラーを奨励すると言うのは、Javascriptがあまりにも多くの関数を奨励すると言うのと同じだと思います。ええ、あなたはどちらかの増殖に夢中になることができます。または、反対のことをして、必要に応じて正確に機能させることもできます。一般に、アプリは必要なだけ複雑にする必要があり、それ以上は複雑ではないことを常に忘れないでください。有名なコーダーの人がそれを使用したという理由だけでなく、それが「燃えさしの方法」であるように見えるという理由でさえ、特定のアーキテクチャやパターンを使用する必要はありません。関心の分離、MVCなどの「UniversalGood Things」でさえ、完全に理解し、ニーズを満たす範囲で使用する必要がある原則とモデルです。正しい理由でルールやパターンを選択的に破る能力は、プログラミングの神々の教義への奴隷的な献身よりも、偉大なハッカーの兆候をはるかに物語っていると思います。これは工芸品であり、宗教ではありません。（しかし、YMMV。おそらく、私のようなコーダーのために予約された特別な地獄の輪があります。私はそれに賭けています。）

Emberに固有のことですが、私は各ビューではなく、データモデルや特定のユーザーワークフローの周りでコントローラーを使用する傾向があります。次に、ルーティング/状態マネージャーをビュー間の接着剤として使用します。私は通常、ビューでイベントマネージャーを使用して、ルーターへの指示の送信など、各ビュー内のブラウザーイベントを処理します。したがって、たとえば、CustomersとProductsを中心に展開するアプリがある場合は、Railsで行う傾向があるのと同じように、それぞれにコントローラーがあります。これにより、各コントローラーは、一部の人々が1か所に持っているよりも多くの関数と計算されたプロパティを保持することになります。また、ビューはコントローラーに配線されているため、必ずしも別のコンテキストでビューを再利用できるとは限りません。そして、はい、これは関心の分離が不十分です。しかし、それが見返りのない複雑さを引き起こす場合、それは絶対的な良いことではありません。

また、コントローラーに関しては、メインデータモデルのサブセットに対してコントローラーが不必要に増殖する傾向があると思います。製品コントローラーがあり、特定のユーザーが収集している製品を比較ツールに保存するとします。ほとんどの人はこのために新しいコントローラーを作成しているようですが、これらをProductsコントローラーやCustomersコントローラー内、またはCustomerモデル上の追加の配列やその他の列挙型にプッシュすることは完全に合法です。これにより、同じ関数とプロパティに依存するオブジェクトがより近いスコープ内に保持されます。Thecontent各コントローラーのオブジェクトは、AFAIKであり、もう1つの列挙可能オブジェクトです。コントローラへの特別な暗黙の参照がいくつかありますが、魔法ではありません。追加のものを使用しないことがわかった機能的な理由はありません。#eachそれらは、バインディング、などでも同様に機能します。

同様に、アプリを100万個のファイルに分割したり、ファイル構造の奥深くに15個ネストしたりするのが大好きな人もいます。基礎となるロジックを視覚化し、残りの部分に明確にするのに役立つ場合は、より強力になります。あなたのチーム。私にとっては、1〜3人のエンジニアリングチームしかいないプロジェクトでは遅くなります。人々はまた、彼らが精通している他のMVCシステム（Railsなど）のファイルベースのスタイルを再現する傾向があります。ファイルは、ビューと他のロジックオブジェクトを分離するために必要な明示的な構造です。これは信仰の品となり、深く根付いた習慣になります。しかし、Javascript MVCでは、そのような目的を果たさないことが多く、暗黙の設計に対して厳密に冗長であることがわかりました。私はEmberアプリ全体に1つの慎重に整理されたファイルを使用する傾向があります（他の非ライブラリJSから分離します）。階層を視覚化するのに役立つインデントとネストがたくさんあります。ファイルに関しては、すべてを適切な場所に適切なタイミングで配信すれば、実行時にすべて同じになります。EmberとJSを使用すると、ファイル構造はチームのニーズに合わせて調整されます。それに応じて調整します。

（重要な警告：100万個のファイルを使用する場合は、プリコンパイラーを使用してそれらをすべてまとめてユーザーに配信することをお勧めします。そうしないと、これらすべてのファイルを個別に配信する際に大きな遅延が発生します。 。）

（もう1つの重要な警告：大規模なチームまたはGitHubのような迅速な毎日のリリーススケジュールでは、ロジックをファイルベースで分離することで、同じファイルに多数のマージを行うよりもバージョン管理が容易になり、マージツールが混乱する可能性があります。 、これは、JSフレームワークによって課せられる技術的要件ではなく、人間のプロセスを管理および監視し、マージを慎重に行うことの問題です。）

（最後の重要な警告：繰り返しになりますが、技術要件と人間/手順要件の違いがあいまいな場合があります。開発者の頭脳を壊すと、アプリも壊れてしまう傾向があります。したがって、人とプロセスに役立つことを実行してください。あなたはそれを構築する際に対処しなければなりません。）

前にも言ったように、YMMV。私の評判スコアからわかるように、私はコーダーの神ではないので、私を無視してかまいません。しかし、私は、複雑さ、ファイル構造、および高レベルの抽象化（ルーティングなど、目的が限定されたシングルページアプリでは実際にはやり過ぎかもしれない）だけを使用する必要があるという考えを支持しています。あなたの要望; そしてそれ以上はありません。

于 2012-08-10T16:58:47.160 に答える
8

かなり大きな残り火アプリを開発していると思います（現時点で約45ビュー）。これは、コントローラーとテンプレートの数がほぼ同じであることを意味します）。確かに私たちのルーターは非常に大きいですが、多くのファイルに分割することで非常に簡単に管理できます。基本的に、各ファイルはアプリの1つの画面を表し、機能セットを維持する責任があります。ルーターの抜粋は次のとおりです。

Router = Ember.Router.extend({
  root: Ember.Route.extend({

  index: Ember.Route.extend({
    route: '/',

  unlogged: Ember.Route.extend({
    route: 'welcome',

    connectOutlets: function (router) {
      var applicationController = router.get('applicationController');
      applicationController.connectOutlet('welcome');
    }
  }),

  logged: Ember.Route.extend({
    route: 'app',

    projects: Ember.Route.extend({
      route: 'projects',

      collection: ProjectsRoute,
      member: ProjectRoute,

      showProjects: function (router) {
        router.transitionTo('projects.collection');
      }
    })
  })
})

次に、同じProjectRouteです。1つのルートに多くの機能があるように見えるたびに、それを分割します。ルートを再度開いて拡張したり、他の機能をプラグインしたりすることもできます。

ProjectState.reopen({

  scenarios: ScenariosRoute,

  showScenarios: function (router) {
    router.transitionTo('scenarios.collection');
  }
});

これはより多くのファイルを意味しますが、すべての機能を同時に操作することは非常にまれであるため、適切な編成では維持するのは難しくありません。通常、同時に開いているファイルは4つ以上ありません（ビュー、コントローラー、テンプレート、ルート）

それがベストプラクティスかどうかはわかりませんが、私たちにとってはかなりうまくいきます

于 2012-07-24T19:24:28.637 に答える