title: How to get a 'codebehind' file for an ASP.NET-MVC View in RC1 to be created by default
body: <p>In RC1 the behavior of the template for creating a view changed.</p>
  
  <p>As explained by Scott Gu's post about the <a href="http://weblogs.asp.net/scottgu/archive/2009/01/27/asp-net-mvc-1-0-release-candidate-now-available.aspx" rel="nofollow noreferrer">release candidate</a> a newly created aspx view doesn't have a code-behind file by default anymore.</p>
  
  <blockquote>
    <p>Based on feedback we’ve changed
    view-templates to not have a
    code-behind file by default.  This
    change helps reinforce the purpose of
    views in a MVC application (which are
    intended to be purely about rendering
    and to not contain any non-rendering
    related code), and for most people
    eliminates unused files in the
    project.</p>
    
    <p>The RC build now adds C# and VB syntax
    support for inheriting view templates
    from base classes that use generics. 
    For example, below we are using this
    with the Edit.aspx view template –
    whose “inherits” attribute derives
    from the ViewPage type:</p>
  </blockquote>
  
  <p>I really like being able to write view specific code in the codebehind to just output the view - especially if I have logic repeated in several parts of the page where I cant justify creating a partial view.</p>
  
  <p><strong>My actual question:</strong> Scott said <strong>by default</strong> - which implies I can change that behavior, but i cannot seem to see where. Is it possible? Manually creatingn a codebehind file and changing things around is a pain.</p>
  
  <p>This causes an additional problem too :</p>
  
  <ul>
  <li>If I refactor the name of my model then the directive in the View isn't updated. This isn't the end of the world, but one distinct advantage of having it fully strongly typed.
  <hr></li>
  </ul>
  
  <p><strong>Addendum:</strong> For those of you wondering WHY I would want a codebehind here are some of the possible reasons. This is a cumulative list of just about everything I've thought of. It goes without saying (well it should) that you mustn't access any data other than that which is already in the model. LINQ would be fine for simple manipulation  of model data, but LINQ to SQL would NOT! MVC is for people who should already know this - thats why I love it - made BY smart people FOR smart people.</p>
  
  <ul>
  <li>Databinding legacy ASP.NET controls - if an alternative is not available or a temporary solution is needed.</li>
  <li>View logic that requires recursion to create some kind of nested or hierarchical HTML.</li>
  <li>View logic that uses temporary variables. I refuse to define local variables in my tag soup! I'd want them as properties on the view class at the very least.</li>
  <li>Logic that is specific only to one view or model and does not belong to an HtmlHelper. As a side note I don't think an HtmlHelper should know about any 'Model' classes. Its fine if it knows about the classes defined inside a model (such as <code>IEnumerable&lt;Product&gt;</code>, but I dont think for instance you should ever have an HtmlHelper that takes a <code>ProductModel</code>. </li>
  <li>HtmlHelper methods end up becoming visible from ALL your views when you type <code>Html+dot</code> and i really want to minimize this list as much as possible.</li>
  <li>What if I want to write code that uses <code>HtmlGenericControl</code> and other classes in that namespace to generate my HTML in an object oriented way (or I have existing code that does that that I want to port).</li>
  <li>What if I'm planning on using a different view engine in future. I might want to keep some of the logic aside from the tag soup to make it easier to reuse later.</li>
  <li>What if I want to be able to rename my Model classes and have it automatically refactor my view without having to go to the view.aspx and change the class name.</li>
  <li>What if I'm coordinating with an HTML designer who I don't trust to not mess up the 'tag soup' and want to write anythin beyond very basic looping in the .aspx.cs file.</li>
  </ul>
  
  <p>I think people are biased against 'code-behind' since it has traditially been interpreted to mean 'event handling code' as opposed to 'the other half of a view's partial class' which is what it is.</p>
  
  <p>Code-behind for views is just fine.</p>
  
  <p>I'm not disagreeing that it clutters up the folder structure a little, but thats what the <code>+</code> icon is for. I just want the ability to create a view with codebehind using 'Add view'.</p>