Как получить файл codebehind для ASP.NET-MVC View в RC1, который будет создан по умолчанию

Question

В RC1 изменилось поведение шаблона для создания представления.

Как объясняется в сообщении Скотта Гу о кандидате на выпуск , вновь созданное представление aspx по умолчанию больше не имеет файла с выделенным кодом.

На основании отзывов мы изменились шаблоны представления, чтобы не иметь файл с выделенным кодом по умолчанию. это изменение помогает укрепить цель представления в приложении MVC (которые предназначено быть исключительно о рендеринге и не содержать никаких не рендеринга связанный код), и для большинства людей удаляет неиспользуемые файлы в проект.

Сборка RC теперь добавляет синтаксис C # и VB поддержка наследования шаблонов представления из базовых классов, которые используют дженерики. Например, ниже мы используем это с шаблоном представления Edit.aspx - чей атрибут «наследует» из типа ViewPage:

Мне действительно нравится возможность писать конкретный код вида в коде для простого вывода вида, особенно если у меня повторяется логика в нескольких частях страницы, где я не могу оправдать создание частичного представления.

Мой фактический вопрос: Скотт сказал по умолчанию - что подразумевает, что я могу изменить это поведение, но я не могу видеть, где. Является ли это возможным? Вручную создавать файл кода и менять вещи - это боль.

Это также вызывает дополнительную проблему:

• Если я произвожу рефакторинг имени своей модели, директива в представлении не будет обновлена. Это не конец света, а одно явное преимущество, заключающееся в том, что он полностью напечатан.

  ---

Приложение: Для тех из вас, кто интересуется, ПОЧЕМУ я хотел бы получить код, вот некоторые из возможных причин. Это совокупный список всего, о чем я думал. Само собой разумеется (ну, должно быть), что вы не должны иметь доступ ни к каким данным, кроме тех, которые уже есть в модели. LINQ подойдет для простого манипулирования данными модели, но LINQ to SQL НЕ подойдет! MVC предназначен для людей, которые уже должны это знать - вот почему я люблю это - сделанных умными людьми для умных людей.

• Унаследованные элементы управления устаревшими элементами управления ASP.NET - если альтернатива недоступна или требуется временное решение.
• Просмотр логики, требующей рекурсии, для создания некоего вложенного или иерархического HTML.
• Просмотр логики, которая использует временные переменные. Я отказываюсь определять локальные переменные в моем супе тега! Я хотел бы, чтобы они как свойства класса представления, по крайней мере.
• Логика, характерная только для одного вида или модели и не принадлежащая HtmlHelper. В качестве примечания, я не думаю, что HtmlHelper должен знать о каких-либо классах 'Model'. Хорошо, если он знает о классах, определенных внутри модели (например, IEnumerable<Product>, но я не думаю, например, что у вас когда-либо будет HtmlHelper, который принимает ProductModel.
• Методы HtmlHelper становятся видимыми из ВСЕХ ваших представлений, когда вы набираете Html+dot, и я действительно хочу максимально сократить этот список.
• Что если я захочу написать код, который использует HtmlGenericControl и другие классы в этом пространстве имен для генерации моего HTML объектно-ориентированным способом (или у меня есть существующий код, который выполняет то, что я хочу портировать).
• Что, если я планирую использовать другой движок представления в будущем. Возможно, я бы хотел оставить некоторую логику в стороне от супа с тегами, чтобы потом было легче использовать его снова.
• Что делать, если я хочу иметь возможность переименовывать свои классы Model и автоматически изменять рефакторинг моего представления без необходимости переходить к view.aspx и изменять имя класса.
• Что делать, если я координирую работу с HTML-дизайнером, которому я не доверяю, чтобы он не испортил «суп-тег» и захотел написать что-нибудь еще, кроме простого зацикливания в файле .aspx.cs.

Iдумаю, что люди склонны к «выделению кода», поскольку оно традиционно интерпретируется как «код обработки событий», а не «другая половина частичного класса представления», каковым оно является.

Кодовый код для представлений просто отлично.

Я не согласен с тем, что он немного загромождает структуру папок, но для этого и нужен значок +. Мне просто нужна возможность создавать представление с помощью codebehind с помощью «Добавить представление».

Answer 1

Это действительно не кажется отличной идеей. Каждый комментарий, который я читал, гласил: «Не используйте код позади; мы хотели бы, чтобы его там не было». И я согласен. Вы можете попробовать написать свою логику в методах расширения (традиционно для HtmlHelper), например здесь .

Answer 2

Чтобы ответить на ваш вопрос напрямую, я не думаю, что вы можете изменить это значение по умолчанию. Вы можете попробовать изменить шаблон (который будет где-то в% programfiles% \ Microsoft Visual Studio 9.0 \ Common7 \ IDE \ ItemTemplates "), но я точно не знаю.

Однако «MVC-путь» для этого сценария, вероятно, заключается в создании настраиваемого помощника в отдельном классе.

Недавно я написал веб-приложение, которое использовало Gravatar (http://www.gravatar.com) для генерации изображений профиля, и я продолжал писать одни и те же пользовательские теги во всех своих представлениях, поэтому создал помощника: Html.Gravatar ()

Просто создайте статический класс "MyHelpers" или "GravatarHelpers" или "FooHelpers" и добавьте методы статического расширения с сигнатурами, подобными этим:

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

или, если вы используете строго типизированные представления (ViewPage ) и хотите воспользоваться этим, вы можете расширить HtmlHelper

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

Вы можете легко отключить HtmlHelper для UrlHelper или AjaxHelper. Я полагаю, что вы также можете получить доступ к ViewData и т. Д. Из свойства ViewContext помощника.

Answer 3

FYI - В Visual Studio 2010 простое добавление файла кода с соответствующим именем в файл, содержащий представление, автоматически свяжет новый файл кода с представлением. Вам не нужно удалять и повторно добавлять файлы, чтобы они связывались. Однако вам все равно придется изменить унаследованные классы, чтобы они работали, как описывает @Harry.

Answer 4

Я считаю, что код за файлами все еще полезен. В то время как многие люди говорят о том, как они плохи, потому что они предоставляют метод, чтобы сломать шаблон проектирования, к которому стремится MVC, они не делают этого по своей сути. Вы можете сказать, что представление должно быть глупым, но я думаю, что, вероятно, более правильно сказать, что представление не предполагает заниматься сложной бизнес-логикой. Тем не менее, он должен сам заботиться о аспектах презентации. Таким образом, в представлении информации все еще есть элементы, которые требуют кода, выходящего за рамки простого HTML. Из соображений разделения интересов (не говоря уже о чистой читаемости представления) следует, что разметка связана с разметкой с кодом, поддерживающим ее там, где необходим код.

Луис Абреу написал хорошую статью на эту тему

Кодовые файлы в asp.net mvc не являются злыми

Answer 5

Я ответил на этот вопрос здесь :

Как добавить страницу с выделенным кодом в частичное представление

Кажется, это не было особенно сложно, и вполне выполнимо Этот ответ работал для частичного 'ViewUserControl', но то же самое должно применяться

Хорошо.

Первый: добавить файл класса с условным обозначением .cs (т.е. view.ascx.cs)

Второе: добавить «using System.Web.Mvc;» в класс

В-третьих: изменить класс на Inherit с «ViewUserControl <>»

Четвертый: добавить следующее в заголовок View:

CodeBehind="View.ascx.cs" Inherits="Project.Views.Shared.View"

В-пятых: скопируйте файлы из решения и перетащите обратно, чтобы заново связать их вместе

Примечание. Чтобы это работало с обычным представлением MVC, вам просто нужно наследовать класс от ViewPage

Answer 6

Я также хотел бы, чтобы код по умолчанию был по умолчанию, но я не могу найти способ его изменить. На этой странице объясняется, как добавить код на страницу: http://msdn.microsoft.com/en-us/magazine/cc301556.aspx.

По моему мнению, классы code-behind идеально подходят для контроля привязки данных и внесения небольших изменений в данные в случае необходимости (например, форматирование даты и валюты). Кроме того, повторители на сегодняшний день являются самым простым способом отображения списков данных, я до сих пор не могу найти способ перебора коллекции анонимных типов, и только наличие оператора for на странице напоминает мне PHP: S