Ext JS 4でのアプリケーションのアーキテクチャ

スケーラビリティ、保守性、およびアプリケーションの柔軟性は、主にアプリケーションアーキテクチャの品質によって決まります。 残念ながら、アプリケーションアーキテクチャは多くの場合、二次的な要因と見なされます。 概念とプロトタイプは大量のアプリケーションに変わり、コード例は多くのアプリケーションの基盤に「そのまま」コピーされて貼り付けられます。 プロジェクトの開始時に急速な進展が見られるため、簡単な方法をお勧めします。



ただし、時間の節約は、アプリケーションの保守に必要な時間と比較して比較的低く、スケーラビリティを確保し、多くの場合、アプリケーションの遅延リファクタリングに費やします。 本格的なアーキテクチャをより適切に準備する1つの方法は、特定の規則に従って、ビュー、モデル、リポジトリ、およびアプリケーションコントローラーを実装する前に定義することです。 この記事では、人気のあるアプリケーションを見て、強固な基盤を構築するためのユーザーインターフェイスを構築する方法について説明します。



コード編成





画像

アプリケーションのアーキテクチャは、コードの構造と構造、および使用される実際のクラスとライブラリの両方を記述します。 優れたアーキテクチャを作成すると、次のような多くの重要な利点が得られます。

Ext JS 4では、アプリケーションを作成するときに考慮する規則を定義しました。何よりもまず、単一のディレクトリ構造です。 この単純な構造は、アプリディレクトリ内のすべてのクラスを整理します。アプリディレクトリには、モデル、ビュー、コントローラー、およびリポジトリの名前空間を整理するサブフォルダーが含まれます。



Ext JS 4はアプリケーションの構造化に関するベストプラクティスを提供しますが、ファイルとクラスの命名規則を変更することは可能です。 たとえば、プロジェクトの「Controller」コントローラーにサフィックスを追加する必要があると判断する場合があります。例えば、「Users」は「UsersController」になります。 この場合、クラス名だけでなく、対応するファイルの名前にも必ず接尾辞を追加することを忘れないでください。 重要なことは、アプリケーションの作成を開始する前にこれらの規則を定義し、一貫してそれらに従う必要があるということです。 最後に、クラスには好きな名前を付けることができますが、フォルダー(コントローラー、モデル、リポジトリ、ビュー)の名前と構造に関する規則に従うことを強くお勧めします。 これにより、 SDKツールのベータ版で最適化されたコードを取得できます



バランスの達成



アプリケーションのユーザーインターフェイスをビューに分割することは、出発点として適切です。 多くの場合、デザイナーによって作成されたユーザーインターフェイスのスケッチとレイアウトを取得します。 Ext JSを使用して(非常に魅力的な)Pandoraアプリケーションを再作成するように求められ、インターフェースデザイナーから次のレイアウトが提供されていると想像してください。



画像



私たちが達成したいのは、あまりにも詳細な表現や一般的な表現を作成することのバランスです。 インターフェイスをあまりにも多くのビューに分解するとどうなるか想像してみましょう。



画像



インターフェイスを非常に多くの小さなビューに分割すると、コントローラーでビューを使用、制御、管理することが非常に難しくなります。 さらに、各ビューは個別のファイルに配置されるため、作成するビューが多すぎると、ユーザーインターフェイスロジックまたは必要なビューの一部を定義するビューファイルを検索することが難しくなります。



一方で、私たちの考えが一般的すぎることは望ましくありません。なぜなら、これは私たちの柔軟性、つまり物事を変える能力に影響するからです。



画像



この場合、私たちのアイデアはそれぞれ単純化されていました。 ビューのいくつかの部分に特定のロジックが必要な場合、ビューのクラスが責任を持ち始め、維持が難しくなるという事実につながります。 さらに、設計者がインターフェイスのレイアウトについて気が変わった場合、最終的にビューとそのロジックの定義を再編成する必要があり、これは退屈になる可能性があります。



ページ上のビューの位置を毎回リファクタリングせずに簡単に変更できる場合、適切なバランスが実現されます。 たとえば、簡単に移動したり、後で削除したりできるように、広告ユニットを別のビューにする必要があります。



画像



このバージョンでは、各ビューの役割に応じてユーザーインターフェイスが壊れています。 ユーザーインターフェイスを形成するビューの一般的なアイデアがある場合は、実装段階で既に粒度をカスタマイズできます。 2つのビューが実際に1つになるか、ビューが一般的すぎて複数のビューに分割する必要がある場合がありますが、最初の内訳は適切な基礎から始めるのに役立ちます。 今やったと思う。



モデル



アイデアの基本構造ができたので、次にモデルを見てみましょう。 ユーザーインターフェイスで動的データの種類を見ると、アプリケーションに必要なさまざまなモデルに関する情報を取得できます。



画像



トラック(歌)とラジオ局(局)の2つのモデルのみを使用することにしました。 アーティストとアルバム用に、さらに2つのモデルを定義できます。 ただし、ビューと同様に、モデルを定義するときにあまり詳細になりたくありません。 この場合、アプリケーションではユーザーが特定のアーティストの特定の曲を選択できないため、アーティストとアルバムに関する情報を分離しないでください。 代わりに、データはラジオ局ごとに整理され、トラックは中心的な人物です。アーティストとアルバムはトラックのプロパティです。 これは、トラック、アーティスト、アルバムのデータを1つのモデルに結合できることを意味します。 これにより、アプリケーションのデータの処理が大幅に簡素化されます。 また、アップロードする個別のアーティストやアルバムがないため、サーバー側で実装する必要があるAPIを簡素化します。 この例をまとめると、音楽トラックとラジオ​​局の2つのモデルだけができます。



保管施設



アプリケーションで使用するモデルを検討したので、リポジトリについて検討します。



画像



さまざまなリポジトリで必要なものを見つけることは、多くの場合比較的簡単です。 適切な戦略は、ページ上のすべてのデータ関連コンポーネントを識別することです。 この場合、お気に入りのラジオ局すべてのリスト、最後に再生されたトラックのあるスクローラー、および検索結果を表示する検索フィールドがあります。 これらの各ビューは、リポジトリに関連付ける必要があります。



コントローラー



すべてのアプリケーションコントローラにアプリケーションの責任を分散させる方法はいくつかあります。 この例で必要なコントローラーについて考えてみましょう。



画像



ここには、SongControllerとStationControllerの2つのメインコントローラーがあります。 Ext JS 4では、複数のビューを同時に管理できるコントローラーを使用できます。 StationControllerは、新しいステーションを作成し、ユーザーのお気に入りのラジオステーションをStationsListビューにロードするためのロジックを処理します。 SongControllerは、SongInfoビューとRecentSongリポジトリ、およびトラックのような、嫌い、停止、スキップなどのユーザーアクションの管理を行います。 コントローラは、イベントを生成し、アプリケーションイベントをサブスクライブすることにより、相互に対話できます。 追加のコントローラーを作成することもできます。1つは再生を制御し、もう1つはステーションを検索するためのものですが、職務の適切な分離が見つかったと思います。



7回測定し、1回切ります



コードを書く前にアプリケーションアーキテクチャを計画することの重要性についての私たちの考えが、誰かに役立つことを願っています。 アプリケーションの詳細を議論することは、はるかに柔軟で便利なアーキテクチャを構築するのに役立つと考えています。



Tommy Mainzによる投稿。



トミーマインツがSencha Touchをリードしています。 オブジェクト指向JavaScriptの広範な知識とモバイルブラウザーの個々の特性の知識により、モバイルブラウザーのフレームワーク内で可能なことの限界を押し広げます。 トミーは、魅力的なユーザーインターフェイスを作成するために、独自の視点と野心的な哲学をもたらします。 彼の細部へのこだわりは、開発者にとって完璧なフレームワークを見つけたいという願望の実現につながります。

Twitterでトミーをフォローする



All Articles