0

私は、いくつかの個別のクライアント側アプリケーションを持つ大規模なアプリケーションの構築に取り組んでいます。構造にBackbone.jsを使用し、依存関係を管理するためにRequire.jsを使用しています。

これらのアプリケーションのいずれかで共通の機能を利用できるように、モデル化する方法は次のとおりです。

-- libs
-- models
-- collections
-- templates
-- views
-- apps
  -- app_one
    -- libs
    -- models
    -- collections
    -- templates
    -- views    
  -- app_two
    -- libs
    -- models
    -- collections
    -- templates
    -- views
main.js

誰かがこれに似た何かをしたかどうか、そして私が考慮していないこのデザインに明らかな落とし穴があるかどうか知りたいです。

私が見る主な利点は、構造のルートで共通のライブラリ、モデル、コレクション、テンプレート、およびビューをグループ化でき、任意のサブアプリが必要に応じてそれらをインポートしたり、独自のネストされたアプリ固有のアセットを定義したりできることです。構造。

4

2 に答える 2

1

You dont even need to nest anything with requirejs . Your main lib can live in its own folder and differents apps can have their own folder too anywhere on the harddrive. The only issue lies in the way you would call all your dependencies with requirejs and wether or not you would use r.js to bundle different apps in a single file.

于 2012-11-29T16:13:55.337 に答える
0

これは理にかなっており、ほとんどの人がそうしていると思います。

私は通常、モデル/コレクションとビューを分離しないという点でそれとは異なります。代わりに、「モジュール」のディレクトリがあります。モジュールは通常、1 つ以上のモデル、関連するコレクションおよびビューを含む単一のファイルで構成されます。

また、lib フォルダーに複数のバージョンの jQuery が含まれる可能性が高いことに注意してください。これは、あるアプリを更新する時間があり、別のアプリを更新できない可能性があるためです。

require.js によって構造が無意味になるのは事実ですが、それでもコードを整理しておくことは良い考えです。

于 2012-11-29T19:50:31.233 に答える