12

最近、ASP.MVC 2 に夢中になっていて、さまざまなレンダリング エンジンが存在することが最近明らかになりました... Spark は特に私の注意を引きました。

  1. 私は ASP.NET に関する膨大な知識を持っているので、ASP.NET MVC に加えて強化する価値はありますか?
  2. 一般的にそれは価値がありますか？それは本当に問題ですか？それは実際には味の好みのようであり、パフォーマンスはそれほど高くなく、開発者の時間を大幅に短縮することさえありません.
  3. まだ未熟で、インテリセンスのサポート、構文の強調表示のサポート、多くのツール オプションはありません。MVC 2 のみを予備的にサポートしています...

あなたの考えは何ですか？私はおそらくそれだけの価値がないことに傾いています...

4

5 に答える 5

12

3部構成の質問に順番に答える...

  1. 新しいことを 1 つずつ学ぶことはおそらく良い考えです。特に、MVC の例とチュートリアルのほぼすべてが WebForms 構文になるためです。とはいえ、「実際の」プロジェクトではなく、実験ソリューションで学ぶのが最善です。そのため、MVC の概念を理解したと感じたら、新しいサンドボックスを作成して、いくつかの MVC + Spark ページを試すことをお勧めします。

  2. メモリの負荷やプロセッサの使用率に関するパフォーマンスは、最大の Web サイトを除いて、おそらく最も重要な考慮事項ではありません...開発者、およびデザイナー/クリエイティブの時間への影響は、最初は小さいかもしれませんが、累積的で非線形です. . 事前に少し単純化することで、将来の苦労を大幅に軽減できます。「シンプルでプレーンな構文」は、Spark ビュー エンジンの前提の基礎です。

  3. それはとても真実です。経験の洗練と改良は、ツールと最新の IDE の最も高価な部分です。それが、ほとんどの OSS Web スタックが優れたエディター (咳TextMate咳) から始まり、そこから発展していく理由だと思います。Spark を使用すると、csharp 言語の Intellisense を取得できますが、これは明らかにツール サポートの下限です。

逸話ではありますが、測定する方法の 1 つは、Spark の使用を後悔して元に戻す人の数です。私は多くのことを確信していません.MVC 2のサポートを開始するのが遅れたため、疑問に思っている人もいました.

于 2010-03-04T20:27:30.340 に答える
8

ASP.NET MVC で何をしたいかによって異なります。私たちはそれを使って大規模なエンタープライズ アプリを構築している最中ですが、Spark を使用したかったと少し思います。しかし、これは約 200 回目のビューが完成した後で初めて、フレームワークに十分に慣れ、何か他のものにスナップすることを検討することができました。

最初に通常のビュー エンジンを使用していくつかの小さなアプリを作成することをお勧めします。「タグ スープ」に苦労している場合は、一歩下がってその理由を検討してください。多くの場合、ビューをタグ スープで埋めるのではなく、より良い ViewModel を作成してデータをマップするか、html ヘルパーを作成するか、部分ファイルを使用する必要があることを意味します。

ただし、ビューで条件付きの膨大なループ ロジックが必要な場合があり、そのような場合に Spark が必要になる場合があります。両方並べて使えるのも嬉しいポイント。だから私はデフォルトのままでいいと思います。

于 2010-03-03T05:59:18.660 に答える
5

Web アプリにおける MVC の優れた点の 1 つは、多くの開発者が遭遇する主な問題の 1 つである HTML のベア メタル (レンダリングされた HTML の完全な制御の欠如) に近づけることができることです。

Spark は ASP.net よりも生の HTML にかなり近い

一般に、プログラミングを行っていない HTML デザイナーは、ASP.net よりも Spark を理解し、それを操作する可能性が高くなります。

これが問題になる場合は、Spark を使用してください。それ以外の場合は、必要なレンダリング エンジンを使用してください。nhamlで何か違うものを確認してください

于 2010-03-02T21:49:44.593 に答える
4

実際、私は数か月前に同じ選択を迫られましたが、教育目的ではなく、実際のビジネス アプリケーションのためでした。私の答えは「スパークする」です。

確かに、インテリセンスやプリコンパイル用のインクルードなど、いくつかのトリッキーなものがあります。しかし、私の見通しからすると、メリットはより重要です。ビューの「読みやすさ」は、spark の方がはるかに優れています。パーシャルへのよりエレガントな分離があります (これも私の個人的な意見です)。また、サイト ローカリゼーションの Spark の方法がより自然であることもわかりました (MyView.spark、MyView.de.spark、自動フォールバック付きの MyView.de-DE.spark、マスター レイアウトも同様)。小さな便利な機能がたくさんあります。何よりも私は ${} と !{} を使って html エンコーディングを取得したり、それを回避したりするのが大好きです。私のアプリケーションは、事前にコンパイルされた中程度の信頼で動作します。

むしろ、spark は実際の開発で使用できるほど成熟していると言えます。しかし、完璧ではありません。

于 2010-03-03T23:24:34.357 に答える
1

この質問には回答があり、Razor が登場する前に尋ねられたことは知っていますが、新しいプロジェクトを開始する場合は Razor を選択します。私は現在、Spark を使用したプロジェクトを行っていますが、WebForms よりも優れた選択であったことに間違いなく同意します。しかし、風景が変わったので、今日決断しなければならないとしたら、別のものを選ぶでしょう.

理由

  • Spark の主な開発者は Microsoft に雇われた (おそらく Razor で働いていた)
  • 今日の時点で、Spark の最後の安定版ビルドはほぼ 1 年になります。
  • 構文はかなり似ています
  • アウトラインサポート。Web ページを作成するとき、html のセクションを折りたたむことができることが重要です。Razor はこれをサポートしていますが、Spark はサポートしていません。

Razor の優先順位が間違っているという議論には同意しません。彼らは、Razor のデフォルトはコードであり、いくつかのマークアップと Spark はその逆であると言います。私はその議論にある程度同意します。ツールは、両方のビュー エンジンがコードレス ビューまたはコードフル ビューのいずれかを持つことができます。それを最終的にタイプするのは男次第です。

于 2011-01-25T17:40:51.303 に答える