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