Вспомогательные методы для генерации небольших фрагментов HTML

Question

Я использую ASP.NET MVC для разделения своих HTML-представлений из моих моделей. Однако есть определенная ситуация, которая меня немного сбивает с толку.

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

В настоящее время это делается с помощью частичных представлений, передавая соответствующую часть данных с помощью параметра модели, как таковой:

@Html.Partial("UserInfo", this.Model.CurrentUser); 
@Html.Partial("UserInfo", reply.PostedBy); 

И так далее. Все это прекрасно работает.

Я недавно воспользовался требованием, которое чувствует, что оно растягивает разумные пределы для этой модели, однако - оно будет включать в себя очень большое количество частичных представлений с количеством слов TINY в каждом, вложенным много раз. Время разрешения страницы, похоже, начинает немного выходить из-под контроля, и я подозреваю, что объем поиска и отражения частичных представлений может иметь какое-то отношение к нему.

Обратите внимание: Я предполагаю, что дублирующий HTML, который должен быть тем же, все еще следует избегать. Я мог бы упростить гнездо, имея копии HTML в некоторых элементах управления более высокого уровня, но мне кажется, что это повреждает ремонтопригодность.

Для внутреннего большинства мне кажется более целесообразным создавать статические вспомогательные классы, которые генерируют и возвращают требуемый HTML-код, однако, несмотря на то, что сам MVC делает это с помощью класса-помощника , он чувствует себя так идет против шаблона MVC.

• Можно ли использовать статические вспомогательные классы для генерации небольших фрагментов HTML?
• Куда стоит статический класс UserInfo? Просмотры? Контроллеры? В другом месте?

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

Статический помощник - это ширина волосков от метода расширения, потребляемого в способе, который, по-видимому, делает весь подход действительно похожим на простое добавление вспомогательного метода к модели. Это, конечно, то, что MVC пытается уйти от прежде всего!

Обратите внимание: Я не пытаюсь прокрасться по правилам или жаловаться! Я просто хочу подходить к этому как «по шаблону», насколько это возможно. Если будет много и много частичных представлений, я буду придерживаться этого и настроить производительность, насколько это возможно.

Answer 1

Я считаю, что существует четыре общих решения для повторного использования html, как вы хотите в вопросе.

1. Частичные виды (@Html.Partial);
2. Действия детей (@Html.Action);
3. Пользовательские статические помощники (@Html.Whatever, @Url.Whatever, методы расширения для ваших моделей и т. Д.);
4. Бритвы помощников. (@helper)

Допустимо ли использовать статические вспомогательные классы для создания небольших фрагментов кода?

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

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

Где должен находиться статический класс UserInfo? Просмотры? Контроллеры? В другом месте?

Эти вещи относятся к виду с точки зрения рисунка. Если вы спросите, какие папки должны быть заполнены в решении, я бы порекомендовал им специальную папку (возможно, HtmlHelpers). Вероятно, для общих помощников бритвы существует ограничение на размещение в папке App_Code.

Я думаю, что следующие вопросы дадут вам больше о том, как выбрать между ними:

1. Creating reusable HTML view components using Razor in ASP.NET MVC;
2. How to create reusable control in ASP.NET MVC;
3. How to create a reusable piece of HTML with dynamic contents;
4. ASP.NET MVC: Razor @helper vs extension methods to HtmlHelper - which is preferred?.

UPDATE

Там может быть пятое решение в новом ASP.NET MVC: View Components. Насколько я читал, вы можете использовать их вместо дочерних действий.

Answer 2

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

Например, информация о пользователе вещи вы в настоящее время в том числе через частичный вид, кажется, что это было бы лучше ребенка действия:

[Authorize] 
public class AccountController : Controller 
{ 
    ... 

    [ChildActionOnly] 
    [AllowAnonymous] 
    public ActionResult UserInfo() 
    { 
     // get your user info here 
     return PartialView("UserInfo", userInfo); 
    } 
} 

И тогда в вашем представлении/расположение:

@Html.Action("UserInfo", "Account") 

Затем вам не нужно следить за тем, чтобы пользовательский объект был заполнен любой моделью просмотра, с которой вы работаете.

Далее, вспомогательные методы Бритва как Html.Partial и т.д. сами по себе являются просто расширениями либо HtmlHelper или UrlHelper для Url.* хелперов. Нет ничего плохого в добавлении собственных методов расширения. Было довольно распространено распространять HtmlHelper с пользовательским номером EnumDropDownListFor, например, до того, как он превратился в MVC 5 из коробки. Тем не менее, расширения действительно лучше всего подходят для небольших фрагментов HTML, которые, похоже, вы хотите с ними работать. Для больших блоков HTML просто имеет смысл использовать частичные. Но все работает. Это в значительной степени зависит от вас, чтобы просто решить, что наиболее важно для вашего приложения.