2

Ember での「MVC」の実装は、私が慣れ親しんだものとは少し異なるようです。Ember のフローは、ビジネス ロジックをコントローラーに配置することを奨励しているかのように感じます。これは意図的なものですか、それとも単に多くの時代遅れの、または簡単な例、チュートリアル、フィドルの混乱した結果ですか?

PS: これらの「時代遅れまたは簡略化された」例はすべて、その時代には非常に貴重であり、著者の努力に心から感謝しています :)

4

1 に答える 1

4

Ember の MVC アーキテクチャは、典型的な Web アプリのアーキテクチャと直接比較できるものではありません。主な違いは、サーバー MVC アーキテクチャは実際にはリクエスト スコープのみを処理するのに対し、ember アプリにはリクエストの概念がないことです。アプリ全体を利用できるか、まったく利用できません。

サーバー側のコードは主にモデルの操作と通知を行うため、ファット モデル/シン コントローラーを使用することは理にかなっています。コントローラーは基本的に、モデルへのルーターです。

Ember のコントローラーをmodel-proxyと見なすと、コントローラーをファットにする方が理にかなっています。すべてのロジックはコントローラーに委任され、モデルは実際にはオブジェクトを提供するためだけに存在します。簡略化したレイアウトを次に示します。

サーバー側のアーキテクチャ

View       - Displays information
Controller - Delegates request to relevant model, 
             calls the appropriate view with relevant (manipulated) data
Model      - (Fat) Most of the application's thinking happens here,
             calls the database for records
(database) - Serves records as requested

エンバー アーキテクチャ

Router        - Sets up which template/view/controller to use for the page
Template/View - Displays information from the controller
Controller    - All interactive logic goes here,
                interacts with model for records
Model         - Record store which calls server side api for additional records

ご覧のとおり、ember モデルはサーバー側のデータベース機能に似ているのに対し、ember コントローラーはサーバー側のコントローラーに似ています。

詳細については、ember ページのCore ConceptsとIntroduction to Controllersを参照してください。

于 2013-05-30T08:37:20.420 に答える