5

私は Javascript + BackboneJS (MVC フレームワーク) + RequireJS フレームワーク内で作業していますが、この質問はやや一般的です。

バックボーンでは、ビューは従来のビューとコントローラーの組み合わせであり、HTML テンプレートは従来の MVC ビューであることを説明することから始めましょう。

これについてしばらく頭を悩ませていましたが、正しい/実用的なアプローチがどうあるべきかわかりません。

多くのコードが依存するユーザー設定 (単位系、言語選択など) を含む User オブジェクトがあります。

一部のビューは、テンプレートを使用せずに (マッピング ライブラリやグラフ ライブラリなどのサード パーティのライブラリを使用して) ほとんどの作業を行うため、たとえば、単位変換を処理するためにユーザー オブジェクトに依存しています。私は現在、カプセル化をあまり壊さずにその依存関係を管理するために RequireJS を使用しています。

ビューの一部は、それ自体ではほとんど作業を行わず、Model データのみをテンプレート エンジン/テンプレートに渡します。これは作業を行い、単位変換などのために User オブジェクトに依存します。この依存関係をテンプレートに渡す唯一の方法は、それをモデルに注入し、モデルをテンプレート エンジンに渡すことです。

私の質問は、このように広く必要とされている依存関係をどのように処理するのが最善でしょうか? - どこからでもアクセスできるアプリ全体の参照/グローバル オブジェクトを作成しますか? (YUK) - RequireJS の管理された依存関係を使用します。一般的には、具体的なオブジェクトではなく、クラス/オブジェクト定義に対して管理された依存関係の読み込みを使用することのみが推奨されます。- または、依存性注入のみを使用し、その依存性を必要とするすべてのものに手動で渡しますか?

4

3 に答える 3

4

純粋に技術的な観点から言えば、特に JavaScript では可換グローバル (変更される可能性のあるグローバル) は危険で間違っていると私は主張します。特に、JavaScript は非同期で実行されるコードの部分でいっぱいです。次のコードを検討してください。

window.loggedinuser = Users.get("Paul");
addSomeStuffToLoggedinUser();
window.loggedinuser = Users.get("Sam");
doSomeOtherStuffToLoggedinUser();

ここで、addSomeStuffToLoggedinUser()どこかで非同期に実行する場合 (たとえば、ajax 呼び出しを実行し、最初の ajax 呼び出しが終了したときに別の ajax 呼び出しを実行する場合)、2 番目に到達するまでに、新しいログイン ユーザー ("Sam") に何かを追加している可能性があります。 ajax 呼び出し。明らかにあなたが望むものではありません。

そうは言っても、私は、関数から関数へと無限に常に渡されるユーザーオブジェクトを持つことの支持者ではありません。

個人的には、この 2 つの悪のどちらかを選ばなければならないので、おそらく原子力発電所か何かを建設する場合を除いて、「めったに変わらない」ものに対してグローバルな範囲を選択します。そのため、ログインしているユーザーを自分のアプリでグローバルに利用できるようにする傾向があります。何らかの理由で一部の呼び出しが非常に遅く実行され、1 人のユーザーがログアウトし、他のユーザーが直接ログインする状況が発生した場合、何かというリスクがあります。奇妙なことが起こるかもしれません。(繰り返しになりますが、流星が私のアプリをホストしているデータセンターに衝突した場合、何か奇妙なことが起こる可能性もあります...私もそれから保護していません)。実際に考えられる解決策は、誰かがログアウトしたらすぐにアプリ全体をリロードすることです。

だから、それはすべてあなたのアプリに依存すると思います。それを改善する (そして、まだオブジェクト指向のカルマ ポイントを取得しているように感じさせる) ことの 1 つは、データを名前空間付きのシングルトンに隠すことです。

var myuser = MyApp.domain.LoggedinDomain.getLoggedinUser();
doSomethingCoolWith(myuser);

それ以外の

doSomethingCoolWith(window.loggedinuser);

結局はほとんど同じなのに…

于 2012-10-02T18:54:46.647 に答える
1

TDD アプローチを考えると、これをどのようにテストしますか? DI は新しいプロジェクトに最適ですが、JS は、テスト時に具体的なグローバルな依存関係を処理するための柔軟なオプションを提供します。つまり、コンテキストの構築です。さかのぼって、Yahoo は、すべてのモジュールが疎結合で相互に依存しないモジュール パターンを作成しましたが、グローバル コンテキストを使用しても問題ありませんでした。そのグローバル コンテキストにより、常に再利用されるものに対して、アプリの構築をより実用的にすることができます。それを慎重に/控えめに適用する必要があり、それらが動的であるという非常に強力なケースが必要なだけです。

于 2012-10-02T19:00:49.510 に答える
1

あなたはすでに自分の質問に答えていると思います。他の誰かにそれを言ってもらいたいだけです:) DIを使用しますが、とにかくそれを使用するには参照する必要があるため、その依存関係をすべてに「手動で」渡すわけではありません。

于 2012-10-02T18:21:53.430 に答える