如何获得一个“codebehind'文件的ASP.NET-MVC视图中RC1为默认生成 [英] How to get a 'codebehind' file for an ASP.NET-MVC View in RC1 to be created by default

查看:109
本文介绍了如何获得一个“codebehind'文件的ASP.NET-MVC视图中RC1为默认生成的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在RC1的模板创建一个视图的行为改变。

In RC1 the behavior of the template for creating a view changed.

作为解释的斯科特谷的帖子关于<一个href="http://weblogs.asp.net/scottgu/archive/2009/01/27/asp-net-mvc-1-0-release-candidate-now-available.aspx"相对=nofollow>发布候选一个新创建的ASPX视图没有一个code隐藏文件默认了。

As explained by Scott Gu's post about the release candidate a newly created aspx view doesn't have a code-behind file by default anymore.

根据反馈,我们已经改变   视图-模板不具有   code-落后默认文件。本   变化有助于强化的目的,   意见在MVC应用程序(这是   旨在纯粹约渲染   并且不包含任何非渲染   相关code),对于大多数人   消除了未使用的文件   项目。

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.

RC版本现在增加了C#和VB语法   为继承视图模板支持   从使用泛型基类。   例如,在下面我们使用这   与Edit.aspx视图模板 -   他的继承属性提炼出来   从的ViewPage类型:

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:

我真的很喜欢能够编写查看特定code在codebehind刚刚输出的看法 - 特别是如果我有逻辑重复的网页,我不能证明创建一个局部视图几部分组成

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.

我的实际问题:斯科特说默认 - 这意味着我可以改变这种行为,但我似乎无法看到。可能吗?手动creatingn一个codebehind文件和改变周围的事物,是一种痛苦。

My actual question: Scott said by default - 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.

这会导致另外一个问题太多:

This causes an additional problem too :

  • 如果我修改我的模型的名称,然后在视图该指令不更新。这不是世界末日,但有它的一个明显的优势完全强类型。
  • 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.

附录:对于那些你想知道为什么我会想要一个codebehind这里是一些可能的原因。这是刚才的一切我想到的累积列表。不用说(也应该),你不能访问比这已经是模型中的其他任何数据。 LINQ将是罚款,简单的操作模型数据,但LINQ to SQL的不会! MVC是谁的人应该已经知道这一点 - 这就是为什么我喜欢它 - 由聪明的人聪明的人

Addendum: 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.

  • 在传统的数据绑定ASP.NET控件 - 如果选择是不可用或临时的解决方案是必要的
  • 查看逻辑,需要递归创造某种嵌套或分层的HTML。
  • 查看使用临时变量的逻辑。我拒绝我的标记汤定义局部变量!我希望他们作为最起码的视图类属性。
  • 逻辑,是特定只有一个视图或模型,不属于一个HtmlHelper的。作为一个方面说明,我不认为一个HtmlHelper的应该知道任何模型类。它的罚款,如果它知道一个模型中定义的类(如的IEnumerable&LT;产品&GT; ,但我不认为如你曾经有一个HtmlHelper的,需要一个产品型号
  • HtmlHelper的方法最终成为可见从您的所有意见,当你键入 HTML +点,我真的希望尽量减少这个名单尽可能。
  • 如果我想编写使用code HtmlGenericControl 和其他类的命名空间中生成我的HTML在面向对象的方式(或者我有现有的$那这是否是我想要的端口C $ C)。
  • 如果我打算在未来使用不同的视图引擎。我可能想保留一些逻辑除了标签汤,使其更容易在以后重复使用。
  • 如果我希望能够重命名我的模型类,并让它自动重构我的看法,而不必去到view.aspx并更改类的名称是什么。
  • 如果我协调与HTML设计谁,我不相信,以免影响了标签汤,并希望写干啥,超出了.aspx.cs文件中非常基本的循环是什么。
  • Databinding legacy ASP.NET controls - if an alternative is not available or a temporary solution is needed.
  • View logic that requires recursion to create some kind of nested or hierarchical HTML.
  • 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.
  • 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 IEnumerable<Product>, but I dont think for instance you should ever have an HtmlHelper that takes a ProductModel.
  • HtmlHelper methods end up becoming visible from ALL your views when you type Html+dot and i really want to minimize this list as much as possible.
  • What if I want to write code that uses HtmlGenericControl 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).
  • 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.
  • 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.
  • 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.

我觉得人有偏见反对code-背后',因为它已经traditially被PTED指事件处理code',而不是'视图的分部类的另一半跨$ 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.

code-背后的意见就好了。

Code-behind for views is just fine.

我不是不同意,它杂波文件夹结构有点,但多数民众赞成什么 + 图标适用。我只是想创建一个codebehind使用添加视图视图的能力。

I'm not disagreeing that it clutters up the folder structure a little, but thats what the + icon is for. I just want the ability to create a view with codebehind using 'Add view'.

推荐答案

要直接回答你的问题,我不认为你可以更改此默认。你可以尝试修改模板(这是什么地方可以在%ProgramFiles%\微软的Visual Studio 9.0 \ Common7 \ IDE \的ItemTemplate),但我不知道是肯定的。

To answer your question directly, I don't think you can change this default. You could try modifying the template (which would be somewhere in %programfiles%\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates"), but I don't know for sure.

不过,MVC-办法对这种情况很可能是创建一个自定义的帮手,在一个单独的类。

However, the "MVC-way" for this scenario is probably to create a custom helper, in a separate class.

我最近写了一个Web应用程序所使用的gravatar( http://www.gravatar.com )生成我的照片,我一直写相同的自定义&LT; IMG&GT;标签在我的意见,所以我创建了一个帮手:Html.Gravatar()

I recently wrote a web app that used Gravatar (http://www.gravatar.com) to generate profile pictures and I kept writing the same custom <img> tags all over my views, so I created a helper: Html.Gravatar()

只需创建一个静态类MyHelpers或GravatarHelpers或FooHelpers,并添加静态扩展方法具有这样的特征:

Just create a static class "MyHelpers" or "GravatarHelpers" or "FooHelpers" and add static extension methods with signatures like this:

public static string Gravatar(this HtmlHelper htmlHelper, string emailAddress) {
    return htmlHelper.Image(...);
}

或者,如果你使用强类型的意见(的ViewPage&LT; T&GT;),并希望利用这一点,你可以扩展的HtmlHelper&LT; T&GT;

or, if you use strongly typed views (ViewPage<T>) and want to take advantage of that you can extend HtmlHelper<T>

public static string Foo<TModel>(this HtmlHelper<TModel> htmlHelper, ...) {
    // Do stuff
    return // Stuff
}

您可以轻松地切换出的HtmlHelper为UrlHelper或AjaxHelper。我相信你也可以从助手一ViewContext属性访问ViewData的,等等。

You can easily switch out HtmlHelper for UrlHelper or AjaxHelper. I believe you can also access the ViewData, etc. from a ViewContext property on the helper.

这篇关于如何获得一个“codebehind'文件的ASP.NET-MVC视图中RC1为默认生成的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆