Architecting Your App in Ext JS 4, Part 1

SenchaのAPIドキュメンテーションにある Architecting Your App in Ext JS 4, Part 1 の翻訳をしました。

Architecting Your App in Ext JS 4, Part 1

アプリケーションのスケーラビリティ、保守性、フレキシビリティは、 アプリケーションのアーキテクチャーのクオリティによって最も左右されます。 残念なことにそれは結果論として扱われることがままあります。 コンセプトの検証のためのコードやプロトタイプのコードが、大規模なアプリケーションになり、 サンプルコードは多くのアプリケーションの中にコピペされます。 プロジェクトの開始時に早く仕事を進めたいからと、そういった誘惑にかられることもあるでしょう。

しかし、それで節約した時間は、プロジェクトの後の方でアプリケーションのメンテナンス、拡張、リファクタリングに費やす時間に比べて相対的に短いものです。 強固なアーキテクチャーを書く用意をするための一つの方法は、 確かな規則に従い、 アプリケーションのビュー、モデル、ストア、コントローラーを実装する前に定義することです。 このアーティクルでは、ポピュラーなアプリケーションを見て、 強固な基盤を作り上げるために、 どのようにユーザーインターフェースを設計するのかを説明します。

コードの組織化

アプリケーションのアーキテクチャーとは 構造と一貫性を提供することであり、 実際にはクラスとフレームワークコードです。 良いアーキテクチャーを構築するといくつかの重要な利点のロックが解除されます。

  • すべてのアプリケーションは同じ方式で動作するので一度学ぶだけでよい。
  • 同じ方式で動作するのでアプリケーション間でコードを共有しやすい。
  • Ext JSビルドツールを使って出荷用の最適化バージョンを作成することができる。

Ext JS 4では、アプリケーションを構築する際に従うべき規則を定義しています。 もっとも見落とせないのは統一されたディレクトリ構造です。 この単純な構造では全てのクラスをappフォルダーの中に配置し、 その中のサブフォルダーはモデル、ビュー、コントローラー、ストアなどのネームスペースになります。

Ext JS 4はアプリケーションを構造化するベストプラクティスを提供しますが、 ファイルやクラスの名前付けに関する、推奨する規則を変更することもできます。 例えば、プロジェクトの中でコントローラーに”Controller”というサフィックスを追加したいと思ったとします。 この場合は例えば”Users”が”UsersController”になります。 この場合にはコントローラーのファイルとクラスにサフィックスを追加するのを忘れないようにしてください。 アプリケーションを書き始める前にこれらの規則を定義し、一貫してそれに従うことが重要です。 クラスの名前をどのようにつけてもかまいませんが、フォルダーの名前付け規則(controller, model, store, view)に従うことを強く推奨します。

そうするとSDKツール(ベータ版)を使って最適化ビルドができるようになります。

バランスを取る

ビュー

アプリケーションのUIを複数のビューに分解するというのはいい方法です。 よくワイヤーフレームやデザイナーが作ったUIモックアップが提供されます。 (とても魅力的な)PandraアプリケーションをExt JSを使ってリビルドするように言われ、 次のようなモックアップがUIデザイナーから提供されたと想像してください。

実現したいことはビューの分割を細かすぎず粗すぎないようにバランスをとることです。 まず、UIビューを多くのビューに分けすぎた場合に何が起こるか見てみましょう。

UIを多くの小さなビューに分割しすぎるとコントローラーからビューの管理や参照や制御をするのが難しくなります。 またビューはそれぞれ1つのファイルになりますので、沢山のビューを作ると言うことは、 UIの断片やビューロジックが定義されたビューファイルを探すのが難しくなります。

一方、ビューをあまりに粗く分けることもしたくありません。 変更する際のフレキシビリティに影響を与えるからです。

このシナリオでは、各ビューが簡易化されすぎています。 ビューのいくつかのパーツにカスタムビューロジックが必要になったとき、 ビュークラスは結局多すぎる責務をもつことになり、 結果、ビュークラスのメンテナンスが難しくなります。 さらに、デザイナーがUIの配置についての考えを変えた場合、 ビューの定義やビューのロジックに大幅な(そして面倒な)リファクタリングをしなければならないはめになります。

リファクタリングすることなくいつでもビューの再配置ができるようにするのが良いバランスです。 例えば、広告を独立したビューにすると、簡単に移動できますし後で削除することもできます。

このバージョンでは、それぞれの役割毎にUIを分割しました。 UIをマークアップするビューの一般的なアイデアがある場合は 実装する時に粒度を調整する事ができます。

2つのビューが1つでよいと気づくときもあるでしょうし、 ビューが大きすぎて複数のビューに分割すべきだとわかるときもあるでしょうが、 最初の段階ではこの方法は良い基本となるでしょう。 そこで、このようにしたいと思います。

モデル

これでビューの基本的構造と配置ができました。次はモデルについてみてみます。 UIの中で動的なデータのタイプを見ることで、 アプリケーションに必要な違うモデルのアイデアを得ることができます。

2つのモデルを使うことにしました。SongとStationです。 ArtistとAlbumというモデルを定義することもできます。 しかし、ビューの時と同じようにモデルを定義するときに細かくしすぎたくないのです。 この場合では、分離したアーティストやアルバムの情報はありません。 なぜなら、アプリケーションはアーティストを指定して曲を選択する機能がないからです。 そのかわり、データはステーションによって組織化されます。 曲が中央点でありアーティストやアルバムは曲のプロパティです。 ということは、1つのモデルの中に曲、アーティスト、アルバムのデータをまとめることができます。 これによりアプリケーションのデータ面を非常にシンプルになります。 また、独立したアーティストやアルバムのデータをロードしないので、 サーバーサイドに実装するAPIもシンプルになります。 結論。このサンプルではモデルは2つだけにします。SongとStationです。

ストア

アプリケーションが使うモデルについて考えました。次はストアについて考えましょう。

必要なストアを見つけるのは比較的簡単です。 良い戦略はページ上のコンポーネントにバインドする全てのデータを決定することです。 この場合、ユーザーのお気に入りのステーションの全てのリストがあり、 最近再生した曲のスクローラーがあり、 検索結果を表示する検索フィールドがあります。 これらのビューはストアとバインドする必要があります。

コントローラー

アプリケーションのコントローラー全体で、 アプリケーションの責務を分割するいつくかの方法があります。 このサンプルに必要なコントローラーについて考えてみます。

ここには2つの基本的なコントローラがあります。SongController と StationController です。 Ext JS 4では1つのコントローラーが同時にいくつかのビューをコントロールできます。 StationController は新しいステーションを生成するのとユーザーのお気に入りステーションをStationsListビューにロードするのをハンドリングします。 SongControllerはSongInfoビューとRecentSongストアを管理するのと、ユーザーのお気に入りへの追加や削除、曲のポーズやスキップの世話をします。 コントローラーはアプリケーションイベントを発火したりリッスンしたりして互いにやりとりします。 別な考えとして再生を管理するコントローラーやステーションを検索する コントローラーを追加することも考えられますが、 このように責任を分解するので良いと思います。

念には念を

コードを書く前にアプリケーション・アーキテクチャを計画することが重要だという 我々の考えを共有することが、役に立つことを望みます。 アプリケーションの詳細を徹底的に話し合うことが、より柔軟で保守性の高いアーキテクチャを構築するのを援助することがわかりました。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です