ASP.NET MVCでMVC対応のTelerikコントロールを使用すると、MVCモデルに違反しますか?
そうでない場合、HTMLを手動でコーディングする際にTelerikコントロールを使用すると、(機能や開発速度に対して)どのようなパフォーマンスの低下が発生しますか?
5 に答える
私はそのデモを作成した人なので、私の意見も共有できると思います。私によると、このサンプル アプリケーションは MVC の原則に違反していません。RadControls は、MVC アプリケーションの ViewState またはポストバックに依存しません (生成された出力を確認して、自分で確認できます。__doPostBack または __VIEWSTATE はありません)。実際、グリッドをバインドしたり、メニューに入力したりするコードを記述する必要がありますが、それでもコードはビュー (ASPX) にあり、プレゼンテーションに完全に関連しています (これも私の意見なので、間違っている可能性があります)。
また、実際にはいくつかの制限があることにも言及する必要があります。組み込み機能 (ポストバックに依存するもの) の一部は MVC では機能しません。ただし、それらの解決に取り組みます。RadControls および ASP.NET MVC に関して特定の質問がある場合は、サポート チケットまたはフォーラム スレッドを開いてください。
パフォーマンス ヒットと手動コーディングに関する 2 番目の質問に対しては、使用しているコントロールに依存すると思います。たとえば、Menu、TabStrip、PanelBar などの Telerik ナビゲーション コントロールのいずれかを MVC で使用すると、大量の手動コーディングを節約できます (メニュー/タブストリップなどにはクライアント側で多くの作業が必要になるため)。インタラクティブな機能 (ドロップダウン オプションなど) と多くの複雑な CSS を提供するためのコード)。したがって、MVC の RadControls は、機能豊富な ASPNET アプリを構築するときに慣れ親しんだ生産性を回復するのに役立ちます。
ポストバックに大きく依存する Grid などのより複雑なコントロールの場合、主に提供されたスタイリングの恩恵を受けます。MVC モデルに適合させるために、Grid のようなコントロールは、ポストバック イベントを URL アクションに「変換」するためにかなりの「カスタム」コーディングを必要とするため、MVC グリッド テンプレートと比べて多くのコードを保存できない場合があります。ただし、スタイリングに多くの時間を節約でき、パフォーマンスの違いは無視できるはずです。
それが役立つことを願っています。
-トッド
これらはWebFormsのPostBackモデルに依存しており、MVCビューと互換性がないと確信しています。おそらくそれらが機能する方法を見つけることができますが、それはMVCの原則に沿ったものではありません。必要に応じて、同じWebサイトでWebフォームとMVCビューを組み合わせることができますが、お勧めしません。
Telerikコントロールを使用することで失われるのは、MVCの利点のほとんどです。関心の分離、テスト容易性の向上、HTMLのスリム化、アーキテクチャのクリーン化です。最終的にTelerikがMVCのコントロールを備えていることに気付いても驚かないでしょう。今のところ、いくつかの一般的なコンポーネントを再利用する必要がある場合は、クライアント側の純粋なJavascript実装または手動でコーディングされたViewUserControlsのいずれかを検討します。
個人的には、MVC で現在のテレリック コントロールを使用することはありません。一部の状況では機能すると思います ( http://telerikwatch.com/2009/01/telerik-mvc-demo-app-now-available.html ) が、かなりビューステート/ポストバック中心であると思います。telerik を知っていると、MVC 互換バージョンがリリースされる予定ですが、その前に多くの作業が必要なようです...