InfoQ

News

ASP.NET MVCとCodebehindファイル

作者 Hartmut Wilms, 翻訳者 編集部 投稿日 2008年10月5日 午前12時28分

コミュニティ
.NET
トピック
.NETフレームワーク
タグ
ASP.NET MVC

ASP.NET MVCコミュニティで話題となっているのは、WebFormsViewEngine使用時にcodebehindファイルが依然として必要か否か、また、codebehindファイルはメリットなのか、デメリットなのか、はたまた問題ですらあるのか、という点である。

ASP.NET MVCは相変わらずデフォルトでWebFormsViewEngineを使用する。ASP.NET MVCアプリケーションにWebFormsのビューを追加すると、Visual Studioは自動的にcodebehindファイルとdesignerファイルを追加する。伝統的なオールインワンのASP.NET Webフォームとして、開発者がビューを使用する傾向にあるかもしれないので、codebehindファイルは時代遅れで、使い方がかなり分かりにくいと思っている人が大勢いる。

Steve Smith氏(リンク)の考えはさらに少々否定的で、ASP.NET MVCにおけるCodebehindファイルを「悪」(リンク)と公言する。なぜなら、Codebehindファイルによって開発者はビューにロジックを加えたくなるのだが、ビューは意図的に「ダム(dumb)」にしておくべきだからである。

手元にあるcodebehindファイルには誘惑されます。ASP.NET MVCの経験がない開発者で(皆そうですね -- 誕生から1年も経っていませんし、なにしろまだリリースされていないのですから)、Webフォームの利用経験がある人は(ほとんど皆がそうでしょう)、これまでいつもそうしてきたように、codebehindファイルにコードを入れるのが自然な流れなのですが、それに抵抗しなければならないのです。codebehindファイルにコードを入れると、ビューのロジック検査が困難になり、最悪の場合、codebehind内のロジックが直接データベースやWebサービスを呼び出すようなことにもなりかねず、その結果、モデルのビューからの分離も完全にバイパスしてしまうのです。

Smith氏は、場合によってはcodebehindファイルは必要悪と説明する。たとえば、強く型付けされた方法でモデルを参照するために、強く型付けされたビューが欲しい場合である。ビューのロジックを格納しておくために codebehindページが利用されることもあり、そうでもしなければビューのロジックでASPXファイルが一杯になるだろう、と論ずる者もいる。大事なことを言い忘れていたが、codebehindファイルは、ASPXファイル上でintellisenseを獲得するためには、規則上、必要となっている。最初の問題に関して、C#やVBの表記の代わりにCLR表記をジェネリクスに組み入れることにより、Codebehindを使わずに強い型付けのViewData(Strongly-Typed ViewData Without A Codebehind)(リンク)を使用する方法をTim Barcz氏(リンク)が示している。

Inherits="System.Web.Mvc.ViewPage`1[[ABCCompany.MVC.Web.Models.LoginData, ABCCompany.MVC.Web]]"

このCLR表記では、アポストロフィの後にジェネリックパラメータのカウント、続いてパラメータと、パラメータ型を含むアセンブリを定義する。

Luis Abreu氏(リンク)はSmith氏に異議を唱え、投稿(リンク)でその反応を示している。ASPXファイルのスクリプトブロック内に依然としてロジックを入れることができるので、「codebehindファイルの排除が『悪い』プログラマーの阻止に十分であるとは確信が持てません」とAbreu氏は言う。「ダム(dumb)」ビューに関する一般的な考えでも意見が食い違う。ビューには「表示関連のコード」を組み入れてもよく、そしてこのコードをコントローラやASPXファイルに直接置くとマークアップとコードの明確な分離が台無しになるので、むしろcodebehindファイルに置くべきである、というのがAbreu氏の見解である。

原文はこちらです:http://www.infoq.com/news/2008/09/aspnet-mvc-codebehind

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

ジャンル別一覧

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。

消費者主導契約を使ったサービス指向開発

この論文では、組織のサービス開発能力改善を目指した実用的な提案をします。

スケーラビリティの構築とパフォーマンスの達成:バーチャルパネル

InfoQ.com向けのこのバーチャルパネルでは、大企業やプロジェクトからスケーラビリティやパフォーマンスの著名人を招待し、みんなが夢に描いているような結果を達成するための秘密を明かしてもらいました。

アジリティのためにコンポーネントチームより機能チームを選ぶ

Craig Larman氏とBas Vodde氏は、どのように、そして、なぜ機能チームがうまくいくのかを説明し、この主要な組織の変化が価値あるものであることを主張します。

仮想化とセキュリティ

仮想化にはたくさんの利点がありますが、かと言って、その上に実装するアプリケーションのセキュリティをないがしろにしてはいけないのです。

Rubyのオープンクラス:猿のようにパッチを当てない方法

最近リリースされたRuby 1.8.7のプレビューリリースをウオッチしていたRails開発者はすぐに1.8.7プレビュー1に関してあることに気がつきました。それは、1.8.7プレビュー1がRailsを破壊してしまうということです。