私は既存の MVC3 アプリケーションに取り組んでいます。通常、MVC3 プロジェクトに取り組んでいるとき、ビュー ( .cshtml) に HTML と MVC3 マークアップが表示されることを期待しています。
ただし、このアプリケーションでは、各ビューには への呼び出ししかありませんXSLTEngine.Raw()。このコードを見ると、(おそらくXSLTEngine.Raw()メソッドによって) HTML としてレンダリングされるように見える要素を含む XML のような構文を含む XSL ファイルが呼び出されます。
View ファイル内の HTML/MVC3 構文ではなく、このコンテンツを XSL ファイルに保存する利点は何ですか?
わかりにくい。アプリケーションは、XSLT が非常に適しているジョブを実行している可能性があります (XSLT は、特定のタスクに最適化された言語です)。または、XSLT に既に存在するコードを再利用している可能性があります。または、XSLT のスキルがあり、別のテクノロジを学習する時間がない人によって作成された可能性があります。または、XSLT に宗教的な愛着を持つ人によって書かれた可能性があります (多くのプログラマーは、特定のプログラミング言語に宗教的な愛着を持っています。つまり、科学的基準ではなく美的基準で言語を選択するということです。XSLT も例外ではありません)。
これらは、「なぜ X は L で書かれているのですか?」という形式の質問に対する回答とほぼ同じです。ここで、X はソフトウェア コンポーネント、L はプログラミング言語です。
XML をデータ ソースとして使用していた古いアプリケーションのポートである場合、MVC に変換する最も簡単な方法は、XML データを再利用し、XSLT を使用して変換することです。
正直なところ、そのようなアプリケーションを移植することはほとんど意味がありません(本質的に、別のフレームワーク上の同じアプリケーションであるため)。
おそらく、エンド クライアント プラットフォーム/デバイスに幅広いサポートを提供することが目的でしょうか?
慣れ親しんだ従来の MVC 機能を使用していないかもしれませんが、それでもコントローラーを使用できます。私の意見では、これは非常に整頓されており、ページの要求/応答を操作 (および整理) するのが簡単になります。パラメーター マッピングの優れた組み込みサポートは言うまでもありません (モデル バインドの可能性もありますが、それが XSL でどのように機能するかはわかりません)。
この短いプレゼンテーションをざっと見てみると、HTML に対する XSLT のいくつかの重要な利点が強調されています。ぜひチェックしてください。