1

私はかなり長い間、Spine.js と CoffeeScript を使用して JavaScript MVC に取り組んできました。私はしばらくの間 Ruby on Rails を開発しているので、モデル、ビュー、およびコントローラーがそれぞれ何を処理する必要があるかを理解しています (それに関する私の適度な経験に基づいています)。しかし、Rails では、(一般的に言えば) 各コントローラーは基本的に一連のビュー (またはページ) を制御し、一度に 1 つ以上のモデルを処理するものであることを既に知っています。（たぶん、私はまだプロではないので、間違っていたら訂正してください）。

しかし、アーキテクチャに関しては、Spine でまったく異なるコンセプトを見つけました。私はそのドキュメントを読み、そのサンプル アプリに飛び込みました。残念ながら、すべての Spine サンプル アプリは単一ページ アプリを処理する方法を示していますが、これは現実の「より大きな」アプリケーションではもはや当てはまらないものです。（Spineを「シングルページアプリ」にのみ使用する必要がある場合は修正してください）。

次のような多くのページ/セクション/モジュールで構成される Web サイト (またはアプリ) があるとします。

1 - サムネイル ベースのリストなどを表示するホームページ 2 - 連絡先ページ 3 - 現在のユーザーのプロファイル管理ページ (通常の CRUD)

各ページは、上記のページへのリンク、検索入力フィールド、およびログアウト リンクを含むヘッダーと同じ主要構造 (またはレイアウト) を持っています (ログイン ページが別であることは既にわかっているので、詳しくは質問しません)。ここで認証）。

ここで難しいのは、パーツ全体を結び付ける方法が本当にわからないことです。Google と StackOverflow で検索しましたが、明確な答えがありませんでした。

1 - スパイン アプリのアプリケーションは 1 ページのみである必要がありますか? つまり、ヘッダーとフッターは固定されていますが、ユーザーがヘッダーをクリックしたタブに基づいてビューをロードおよびアンロードする動的コンテンツ DIV を使用していますか? それとも、各ページをスタンドアロンのスパイン アプリとして扱うべきですか?

2 - 1 つのページに複数のコントローラーがありますか? たとえば、アプリのメイン コントローラーとナビゲーション コントローラー (ヘッダー) は？

3 - 各コントローラーが 1 つのモデル、またはそれに関連付けられたモデルを処理する必要があるというのは本当ですか? (サンプルでは、​​タスク モデルとタスク コントローラーのように、それらの間に常に 1 対 1 の関係がありました)。

4 - アプリのインターフェイス関連の状態変数はどこに保存すればよいですか。現在のユーザーを「記憶」するモデルを作成する必要がありますか? または、さらに参照するためにどのタブを強調表示するかなどです。または、それらをコントローラーに保存する必要がありますか?

5 - 単一ページのアプリ (ただし、多くのセクションまたはモジュールを含む) になる場合、このページ内に読み込まれたセクションごとにコントローラーを用意する必要がありますか?

これらは経験豊富なプログラマーにとっては些細な質問かもしれませんが、どこから始めればよいか本当にわかりません。誰かが私を正しい軌道に導くことができれば、それは素晴らしいことです.

前もって感謝します！

DD

4

1 に答える 1

0

これはとても良い質問だと思います。私の答えはかなり広いので、我慢してください。

私の答えの本質は、選択したフレームワークが何を解決しようとしているのかを理解するために、他のフレームワークに慣れる必要があるということです。あなたの問題は理解できます。他の人々は、いくつかの一般的なことを行うための 1 つの「適切な」方法がないことに苦労しています。ソリューションは、例、ラッパー/拡張機能、および代替フレームワークの観点から作成されました。おそらく、Spine に影響を与え、今でもそれに類似しているBackboneに関連する情報を探す必要があります。

あなたが言ったように、あなたはRailsのMVCに精通しています。そして、Spine の MVC アプローチが登場しますが、これはまったく異なります。これにより、MVC (または一般的には MV*) が非常に異なる実装を持つ広い概念であるというヒントが得られるはずです。結局のところ、Rails は要求ベースのサーバー側フレームワークであり、Spine はクライアント側イベントベースのフレームワークであると考えているかもしれません。その違いは理解できます。クライアント側の JavaScript フレームワークにも統一性はありません。たとえば、前述のバックボーンには、実際にコントローラーの役割を果たす、いわゆるビューがあります。したがって、Spine の作成者が行ったことの 1 つは、わかりやすくするためにビューをコントローラーに名前を変更したことだと思います。JavaScript の MV* は、 Addy Osmaniによって詳細に説明されています。概要もありますJavaScript フレームワークの。

したがって、Spine と Backbone の「問題」の 1 つは、それらがアーキテクチャを決定しないことです。言い換えれば、彼らは十分に独断的ではありません。好きなように使用できますが、この事実はフラストレーションを引き起こします。以下では、あなたの質問に答えようとします：

  1. Spine では、アプリケーションはシングルページ アプリケーション (SPA) である必要はありません。

複数のページがあり、それぞれが独自のコントローラーをロードするアプリを作成できます。この場合、ビューはサーバー上でレンダリングでき、モデルは生成された JavaScript からブートストラップできます。これは、SPA は必要ないが、JavaScript を整理したり、再利用可能なコンポーネントが必要な場合に適しています。

ただし、Spine の機能セット (ルートなど) から判断すると、SPA を念頭に置いて作成されています。

  1. 一般に、SPA や複雑な UI では、UI の一部 (ウィジェット) を分離することをお勧めします。Spine では、コントローラーはそのような分離の手段です。はい、複数のコントローラーを使用し、コントローラーのネストを使用します。おそらく、最上位のアプリケーション コントローラーが必要です。

  2. これは正しくありません (技術的な制限はありません) が、単一の責任の原則により作業が容易になります。

  3. これらの変数を対応するレベルのコントローラーに格納します。これらの値を観察する必要がある場合はモデルとして保存し、それ以外の場合はコントローラー プロパティとして保存します。

  4. ヘッダー、フッター、サイドバー コントローラー、およびアクティブなページを保持する App コントローラーを使用できます。Routes では、対応するコントローラーを作成し、それを App コントローラーに渡します。これにより、メイン領域のコンテンツがそのコントローラーの要素に置き換えられます。これは可能なアプローチの 1 つです。

もう一度：

Backbone/Spine のアプリケーション アーキテクチャに関して、人々は具体性の欠如に悩まされてきました。彼らは、アプリケーション コントローラー、レイアウト マネージャーなどのソリューションを作成しました。バックボーンについては、マリオネット、チャップリン、またはソラックスを見ることができます。それらから学ぶことで、Spine アプリケーションのアーキテクチャを考え出すことができます。幸運を！

于 2013-02-02T23:31:42.823 に答える