和訳:BackboneとAngularを比較する
この記事は、Victor Savkin氏の「Contrasting Backbone and Angular」を翻訳したものです。
※本人から翻訳の許可も頂きました。
和訳自体は自信なく、細かな所は意訳しているので正確にはオリジナルを参照して下さい。日本語として、冗長になってしまった所はすみません。
それと、ちなみにAngularはよくわかってないので、変な和訳してるかも(気づいた方、コメントで教えて下さい)
※ちなみにtitleはcontrastingなので、両者の違いを明らかにするため対比する、なのですが、冗長だったので短くしました。
以下より、本文
アイディアとツールを比較する事は、その対象をより良く知るとても良い方法です。この記事のシリーズで、webアプリケーションを構築する時に、日常的に取り組む必要がある事柄を書きとめ、そしてBackboneとAngularがそれぞれどのように手助けをしてくれるのか示したいと思います。
私たちは何を解決したいのか?
web開発者として私たちが取り組む事の多くは、次のカテゴリーのどれかに当てはまります。
驚く程の事ではありませんが、多くのClientサイドのFrameworkはこれらについての対応をしてくれています。
Backbone
まずはBackboneがこれらの問題を解決するために我々に何を与えてくれるのか見てみる所から始めましょう。
- ビジネスロジック
- Backbone Model と Collection
- DOMの構築
- Handlebars
- 宣言的なViewロジック
- Backbone View
- 命令的なViewロジック
- Backbone.View
- ViewとModelの同期
- StickIt
- UI相互作用の管理
- JS ObjectsとMarionette Controllers
- 状態とRoutingの管理
- Backbone.Router
- コンポーネントを作る事と繋ぐ事
- 手動
http://engineering.nulogy.com/images/backbone_angular/backbone_architecture.png
Backboneについて
平凡なBackboneとAngularを比較する事は公平ではありません。そのため、ここでのBackboneは、Backbone+Marionette+その他プラグインの事とします。
ビジネスロジック
あるアプリケーションの大きなビジネスロジックの小片は、BackboneではModelとCollectionに行く事になります。 しばし、これらのObjectはバックエンドのリソースと一致する事になります。その上、これらはViewを支援する為に使われます。
DOMの構築
BackboneはDOMを構築するためにTemplateエンジンを使います。理論上、あなたが望むエンジンであれば何でも繋ぐ事が出来ます。にも関わらず、実際の所、MustacheとHandlebarsがよく使われています。結果として、BackboneのTemplateはしばしロジックがなく、文字ベースのものですが、必ずしもそうあるべき物ではありません。
Viewロジック
Viewロジックを宣言と命令に分離するアイディアは、古い物です。(元々のMVCに回帰してしまいます。)イベントハンドリングの設定とデータバインディングは宣言的です。それに対して、イベントハンドリング自体は命令的な物です。Backboneはこの2つに厳密なラインを引きませんでした。両者ともにBackbone.Viewに行きました。
ModelとViewの同期
Backboneのミニマリストの性質の為に、データバインディングについての組み込みのサポートはありませんが、幾つかのPluginにより可能になります。(Backbone.StickItのように)
複雑なUI相互作用の管理
全てのUI相互作用は、単純な物と(ObserverSyncronizationを使っての管理)複雑な物(FlowSynchronizationが必要な時)に分ける事が出来ます。
上述の通り、simpleな相互作用はBackbone.Viewがデータバインディングとイベントハンドラを使う事でハンドルする事ができます。また、幾つかは、Backbone.Viewを複雑な相互作用のハンドルをする事でも使いますが、私はこれをお勧め出来ません。Backbone.Viewは既にあまりに多すぎるのです。これこそ、単純な昔ながらのjavascriptのobjectをその代用として使う事の方が、個人的に好きになった理由です。
コンポーネントを作る事と繋ぐ事
Backboneでは、あなたのアプリケーションに最もぴったりとあてはまる方法で、コンポーネントを作って繋ぐための自由を手に入れます。その否定的な側面は、あなたが書かなくてはならない多くの決まったコードの存在があり、付け加えて、よく整理されたコードを維持し続ける事を求める規律があります。
Angular
今から、Angularが同じ問題に対してどのようなアプローチをとっているのか比較してみましょう。
- business logic
- JS Objects
- DOMの構築
- Directives
- 宣言的なViewロジック
- Directives
- 命令的なViewロジック
- Controllers
- ViewとModelの同期
- 組み込みのメカニズム
- UI相互作用の管理
- Controllers
- 状態とRoutingの管理
- Angular UI Router
- コンポーネントを作る事と繋ぐ事
- 依存性の注入
http://engineering.nulogy.com/images/backbone_angular/angular_architecture.png
ビジネスロジック
Angularが目に見えるプロパティーを使わない為に、Modelの実装する時に直面する制限はありません。extendするclassはありませんし、何かに従うインターフェースもありません。あなたは、欲しい物であれば何でも使うのは自由です。(既存のBackboneのModelも含めて)実際の所、多くの開発者は単純な昔ながらのJavascriptのObjectを使っているようです。
TemplateとView
Angularのテンプレートはコンパイル前のDOMの破片です。コンパイルしている間、AngularはDOMサブツリーを変換して、そこに幾つかのJavascriptを取り付けます。このコンパイルの結果、Viewとなる、元とは別のDOMサブツリーが出来ます。他の言葉で言うと、あなたは自身でViewを作らないのです。AngularはTemplateをコンパイルする事でこれを行います。
DOM構築
BackboneはDOMの構築をViewロジックから明確に分けます。前者は、Templateエンジンによって、後者はデータバインディングと命令的なDOMの更新によって行います。その一方で、Angularはこの2つを分けません。どちらもdirectivesという同じメカニズムを使って、DOMの構築を行い、宣言的なViewの態度を明確にします。
Viewロジック
Angularはしかしながら、宣言的なViewロジックと命令的なViewロジックにラインを引きます。前者は、Viewによって、そして後者はcontrollerによって行われます。
ModelとViewの同期
Angularは多くのクライアント側のフレームワークと対照的に、データバインディングを組み込みでサポートしており、それは目に見えるプロパティーに依存する事はなく、代わりに、dirty checkingを使います。
複雑なUI相互作用の管理
既に述べた通り、ControllerはUI要素の命令的なロジックの実装についての責務があります。その上、複雑なUI相互作用を調整するSupervising Presenterとして使われる事が可能です。
状態とRoutingの管理
Backboneと同じように、Angularの中の組み込みのrouterがとても基本的な物で、本物のアプリケーションと繋ぐには十分とは言えません。感謝したいのは、Angular UI Routerプロジェクトの存在です。アプリケーションの状態、View、そしてネストのサポートを管理します。言い換えれば、あなたがrouterに期待する全ての事をやってくれるのです。しかし、あなたはこれに限る事はないでしょう。Backboneのように、他のroutingライブラリー(router.js等)で同じ事が出来るのです。
コンポーネントを作る事と繋ぐ事
AngularはIoC コンテナーを持っていて、それは、いわゆる依存性の注入のようなもので、あなたにmodularなコードを書く事を強制します。これは、再利用性、テストし易さを向上させ、多くの同じ様なコードを取り除く事を助けてくれるでしょう。否定的な側面としては、複雑性が増してしまい、どのようにコンポーネントが作られているのかについてのコントロールが及ばなくなってくる事でしょう。
要約
以上が、webアプリケーションを開発する時に毎日対処している中心的な問題について、BackboneとAngularがどのように取り組んでいるのかについての短い概要でした。このシリーズのパート2で私はBackboneとAngularのビジネスロジックの実装について説明していこうと思います。