つまり、Backbone.View.ExtendとBackbone.Model.Extendを作成しました。しかし、Backbone.Controller.Extendのコーディングは行っていません。では、コントローラーのコードはどこから来たのでしょうか。
2 に答える
バックボーンがModel-View-Controllerの従来の概念とどのように異なるか:
Model-View-Controllerパターンのさまざまな実装は、コントローラーの定義について意見が一致しない傾向があります。それが役立つ場合、バックボーンでは、Viewクラスは一種のコントローラーと考えることもでき、HTMLテンプレートが真のビューとして機能し、UIから発生するイベントをディスパッチします。これをビューと呼びます。これは、単一のDOM要素のコンテンツを担当するUIの論理チャンクを表すためです。
Backboneの全体的な構造をRailsのようなサーバー側のMVCフレームワークと比較すると、次のように構成されています。
Backbone.Model –Railsモデルからクラスメソッドを除いたものに似ています。データの行をビジネスロジックでラップします。
Backbone.Collection –ソート/フィルタリング/集約ロジックを備えた、クライアント側のモデルのグループ。
Backbone.Router – Railsroutes.rb+Railsコントローラーアクション。URLを関数にマップします。
Backbone.View –論理的で再利用可能なUIの一部。常にではありませんが、多くの場合、モデルに関連付けられています。クライアント側のテンプレート– Rails .html.erbビュー、HTMLのチャンクをレンダリングします。
したがって、基本的には、コントローラーをルートに追加するか、モデルやビューに分割することができます。バックボーンはこの点でかなり柔軟性があり、コードを構造化するかどうかはあなた次第です。
これがバックボーンのコントローラーです。