2
  1. Javascript MVC を使用するのはいつですか? なぜ JS-MVC が必要だったのですか？
  2. このデザイン パターンは、コードのメンテナンス、読みやすさ、および多くの Web アプリがクライアント側に出荷されているため、他の言語で有名だったからでしょうか?
  3. 開発者、テスター、およびエンドユーザーがタスクを軽減するのにどのように役立ちますか?
  4. JS-MVC が最も適しているユースケースと、JS-MVC がまったく必要ないユースケースはありますか?
4

2 に答える 2

2

質問 1、2、4

私の見解では、あらゆる種類のデザイン パターンは、本当に必要な場合にのみ適用する必要があります。結局のところ、デザインパターンは簡単ではないからです。それらはソリューションに複雑さを追加しますが、(通常) 特定の種類の問題に対して確立され、機能するソリューションであるという利点も提供します。

それらを使用するかどうかは、実際に構築しようとしているものと、それがどれほど複雑かによって異なります。そうは言っても、おそらく MVC パターンを使用して 200 行の jQuery プラグインを構築するつもりはないでしょう...

しかし、職場では、2 人から 5 人の開発者が同時に 500 日間のプロジェクトに取り組んでいるシングル ページ アプリケーションを作成しています。このような環境では、物事はすぐに複雑になる可能性があり、適切な構造化に従わなければ道に迷ってしまいます。

質問 1 と 2 の答えになることを願っています。

質問 3 の場合:

エンドユーザーは、バグの少ない高品質のアプリを手に入れることを願っていますが、通常は、アプリの基盤となるアーキテクチャに気付くべきではありません (また気にする必要もありません)。

MVC は開発者を支援します

  • アプリのソース コード内を移動するときの向きとして。1 つのソース ファイルに 3000 行のコードがあるアプリを考えてみましょう。4 人の開発者が同時に作業している場合を考えてみましょう。めちゃくちゃですよね？通常はルーティングなども使用する MVC アプリを使用している場合、通常は URL のルートを確認することで、対応するコントローラーがソース コード内にあり、どこに手を入れる必要があるかを知っています。
  • 簡単なテストのために。関心の分離は、単体テストのプラクティスを適用するときに常に有益です。これは、コントローラーがデータやプレゼンテーションのもの (HTML コードなど) に直接結合されていないため、コントローラーをより簡単にテストできるためです。補足として、必ず JavaScript コードの単体テストを行う必要があります。
  • メンテナンス: どういうわけか前のポイントの結果です

「テスター」でどのようなフィギュアを意図しているのかわかりません。彼がユニットまたは受け入れレベルで自動化されたテストを作成する場合、以前の利点もほとんど維持されます。さまざまな種類の入力に対する反応をテストすることでアプリをブラック ボックスとして扱い、ナビゲートするという意味でアプリ全体をテストしている場合、MVC は彼にとって実際には大きな役割を果たしません。それはエンドユーザー向けのようなものです。

ですから、あなたのためにいくつかのことを明確にすることができたと思います. しかし、言ったように、人々がそれに従っているという理由だけでパターンに従うのではなく、それが何らかの利益をもたらすからです.

于 2013-01-12T11:10:28.927 に答える
-1

MVCは、特にクライアント側のレンダリングで多くの作業をしている場合に、コードを構造化するために使用されます。構造がないと、コードは非常に速く複雑になります。

部分的な更新のみが必要な場合にページ全体の更新を待つ必要がない場合、エンドユーザーのユーザーエクスペリエンスははるかに優れています。

  1. コードの構造が明確に定義されている場合は、コード内をはるかに高速にナビゲートするのに役立ちます。
  2. JS MVCフレームワークは、複雑なシステムがあり、AJAXと部分的なページのリロードまたは更新を使用して、より優れたユーザーエクスペリエンスを提供したい場合に最適です。通常、個人のWebサイト、ブログ、またはそのようなものにはMVCを使用しません...
于 2012-12-10T09:20:40.767 に答える