私のバックグラウンドは、主に Microsoft プラットフォームのデスクトップ アプリケーションです。私は最近、ASP.Net MVC で多くの作業を行っており、Web フォームの学習を完全にスキップしました。私は、MVC でビューを作成する際に (Web の専門家ではありませんが) 一番苦労していることに気付きました。MVC で適切なビューを作成するには、HTML と JavaScript にどれだけ習熟しておく必要がありますか? また、標準の Webforms ビュー エンジンを使用する必要がありますか?それとも、私のバックグラウンドを考えると、Spark ビュー エンジンを使用した方が簡単でしょうか?
2 に答える
最近のほとんどの Web 作業では、HTML、JavaScript (およびおそらく jQuery)、および CSS を十分に理解している必要があります。ASP.Net MVC with Spark、デフォルト エンジン、または PHP などの他のテクノロジを使用しているかどうかは問題ではありません。最終的に、ブラウザーは HTML、JavaScript、および CSS しか理解できず、他のものはその最終出力の作成を支援するだけですが、生成したいものを理解する必要があります。
ビュー エンジンに関しては、できるだけ早く本番環境に導入したい当面のプロジェクトではなく、将来の使用のために学習に取り組んでいる場合は、Microsoft の今後のビュー エンジン Razor を検討することをお勧めします。
http://weblogs.asp.net/scottgu/archive/2010/07/02/introducing-razor.aspx
ASP.Net MVC 3 リリース用に構築されており、Spark、NHaml、および既定のビュー エンジンから学んだ教訓を取り入れています。
記事から:
設計目標
「Razor」のプロトタイプを作成して評価する際に、いくつかの設計目標を念頭に置いていました。
コンパクト、表現力、流動性: Razor は、ファイルに必要な文字数とキーストロークの数を最小限に抑え、高速で流動的なコーディング ワークフローを可能にします。ほとんどのテンプレート構文とは異なり、HTML 内でサーバー ブロックを明示的に示すためにコーディングを中断する必要はありません。パーサーは、コードからこれを推測するのに十分スマートです。これにより、非常にコンパクトで表現力豊かな構文が可能になり、クリーンで高速で楽しく入力できます。
習得が容易: Razor は習得が容易で、最小限の概念ですぐに生産性を高めることができます。既存の言語と HTML のスキルをすべて使用します。
新しい言語ではない: Razor で新しい命令型言語を作成しないことを意識的に選択しました。代わりに、開発者が既存の C#/VB (またはその他) の言語スキルを Razor で使用できるようにし、選択した言語で優れた HTML 構築ワークフローを可能にするテンプレート マークアップ構文を提供したいと考えました。
任意のテキスト エディターで動作する: Razor は特定のツールを必要とせず、従来のプレーン テキスト エディターで生産性を高めることができます (メモ帳はうまく機能します)。
優れたインテリセンス: Razor は特定のツールやコード エディターを必要としないように設計されていますが、Visual Studio 内で優れたステートメント補完をサポートします。Visual Studio 2010 と Visual Web Developer 2010 を更新して、完全なエディター インテリセンスを搭載する予定です。
単体テスト可能: 新しいビュー エンジンの実装は、ビューを単体テストする機能をサポートします (コントローラーや Web サーバーを必要とせず、任意の単体テスト プロジェクトでホストできます。特別なアプリ ドメインは必要ありません)。
ASP.Net MVC 3 Preview 1 については、http: //weblogs.asp.net/scottgu/archive/2010/07/27/introducing-asp-net-mvc-3-preview-1.aspx をご覧ください。
特にビュー エンジンに関して言えば、コード ブロックをビューに導入しようとしている場合は、Razor が最も適切な方法です。
あなたのバックグラウンドを考えると、次の質問は「コード ブロックをビューに導入する必要があるかどうかをどのように知ることができますか?」ということになると思います。- 私が恐れている答えは、多くの苦痛と経験を経てあなたに来ることができます. 多くの人がブログ投稿を書いており、マークアップにコード ブロックが混在し、一般にタグ スープと呼ばれる悪夢につながる危険性を説明しています。
Razor (および Web フォーム) がユーザーに代わって行うことは、C# または VB.Net 言語全体のパワーを、豊富な使用法を規定する方法でビューにもたらすことだけです。これが Tag Soup 問題の原因です。
しかし、この方法を使用することで長期的にビューをきれいに保つことができるというある種の錯覚に陥っている頑固者がいまだにいるようです。あなたが一人で、そして永遠にコードに取り組んでいるなら、私はそれが可能であることに同意する傾向がありますが、それは気が遠くなるほど憂鬱なレベルの集中力と決意がなければなりません.
ただし、コードを抽象化してマークアップ用のビューを維持したい場合は、「ここにクイックフィックス」と「そこにハック」を入れたくない場合は、次のことを強くお勧めします。コード中心のビュー エンジンをスキップして、Spark を使用します。
質問に直接答えるという点では、初心者から上級者まで、たくさんのチュートリアルを見つけることができます。ブログとビデオ形式でお勧めするもののいくつかを次に示します。
- http://blogs.msdn.com/b/coding4fun/archive/2010/10/04/10070953.aspx - Jason Haley によって作成されたビュー エンジンの非常に包括的で正確な比較
- http://vimeo.com/13027275 - NDC2010 で著者の Lou DeJardin 自身が行った Spark の初心者向け入門書
- http://vimeo.com/13027900 - 同じ会議で Lou によって提供された、Spark のより高度な使用法に関する別のビデオ。
- http://blog.robertgreyling.com/2010/07/is-razor-just-wolf-in-sparks-clothing.html - Razor と Spark を直接比較対照するブログ投稿
- http://blog.robertgreyling.com/2010/08/spark-bindings-are-you-tired-of-eating.html - マークアップのクリーンアップについて書いたブログ投稿
- http://blog.robertgreyling.com/2010/08/elegant-mvc-with-spark-way-views-were.html - C4MVC の教育および意識向上の演習として準備したオンライン セッション。
とにかく、情報に基づいた決定を下すのに十分な情報が得られることを願っています.
あなたのダブリングで頑張ってください!
ロブ G