Pull to refresh

ASP.NET MVC: Мои правила для Представлений (Views)

Reading time5 min
Views13K
Original author: Chris Brandsma
Я работаю с командой над несколькими ASP.NET MVC проектами с октября 2009. Хотя прошло не так уж и много времени, и я еще не эксперт, я хочу описать ряд правил, которые мы выработали для того, чтобы сделать код немножко лучше. ASP.NET MVC, как и любая новая технология, может быть использована не удачно, а имея неудачные примеры, мы всегда пытаемся сделать код лучше, выбирая оптимальные варианты реализации задач.

Сперва, давайте подумаем о задачах Представления (View), главная его функция — это вставка данных в HTML. Это правило исключает разночтения — не получать данные, не передавать данные, а просто вставлять данные в HTML. И, честно говоря, это достаточно сложно. Подход, которого я всегда стараюсь придерживаться — создавать разметку страницы (aspx) максимально похожую на результирующий HTML. Главная причина такого подхода — приблизить исходную разметку к результирующей, исключив, таким образом, двойную работу. Я хочу видеть «div» в исходной разметке, и быть уверенным что «div» также будет находится и в результирующем HTML.

1. Используйте в представлениях как можно меньше кода


Не воспринимайте это правило буквально, код все же должен быть в Представлении. Например, простой цикл «for» для создание таблицы, или «if» для отображения функционала администратора, но вы не должны определять формат даты время или парсить строки — это то, что для Представления должна делать Модель (Model). Сделайте приблизительный подсчет – если вы видите больше кода C# чем HTML, значит, Вы что-то сделали неправильно.

Я также применяю это правило для Javascript. Раньше я говорил, почему Javascript не должен быть в представлении, поэтому, это не должно быть для вас шоком. Храните JavaScipt в отдельных файлах.

2. Используйте Типизированные Представления (Typed Views)


Это верно для всех представлений, где вы должны передавать данные из Контролера (Controller) в Представление. Сделайте Модель Представления (View Model) для Представления, и передавайте данные через Модель. Это открывает целый ряд возможностей для Вас, таких как типизированные HtmlHelper-ы. В результате, очень редко бывает так, когда я использую Модель Представления между Представлениями или даже Действиями Контроллера (Controller Actions). Я делаю отдельные модели для GET, POST и DELETE. Чем больше, тем веселее.

3. Создавайте Модели Представления для конкретных задач Представления


Да, это не лучший способ реализации Представлений, на первый взгляд. Если вы сделаете Модель Представления слишком общей, в конце концов, Вы вынуждены будете реализовать много логики в Представлении для передачи данных. Ключевой пункт — данные в модели служат представлению, таким образом, вся работа по получению данных в правильном формате должна быть сделана при передаче данных в модель. Я всегда держу это на вооружении, особенно, когда Модель должна определять для элементов html CSS классы. Каким образом, в Представлениях я имею гораздо больше, чем данные из БД.

На заметку: когда станет популярным использование Модели Представления, с данными, заточенными под Представление, очень популярным станет AutoMapper.

4. Собственные Html Helper-ы — прекрасная вещь


Cоздание собственных Html Helper-ров — это очень просто, и, как только Вы научитесь это делать, Вы поймете, они прекрасны. Это простой способ инкапсулировать немного логики и убрать ее из Представления. Используйте их, чтобы инкапсулировать код, который вы применяете в различных частях проекта.

Еще один небольшой «трюк», который я иногда использую — создаю Модели специально для Html Helper-ов. У меня в проекте есть несколько мест, где я должен менять разметку в зависимости от используемого браузера, для этого я создаю Html Helper, который определяет браузер.

5. Стандартные HTML Helper-ы — это великолепно, но не стоит забывать о HTML


Смысл этого правила заключается в том, чтобы понимать какую разметку выдают стандартные HTML Helper-ы. При всей полезности HTML Helper-ов они имеют и некоторые минусы (любые модификации атрибутов «имя» или «значение» очень неприятны). Иногда гораздо легче заменить их стандартным HTML (особенно input), чтобы получить на выходе более прогнозируемый результат. В качестве бонуса, это позволит новому сотруднику легче разобраться в Вашем коде. На данный момент, я использую 50/50 HTML Helper-ы и HTML.

Использование стандартных элементов HTML или HTML Helper-ров – довольно рутинно. Вы вынуждены раз за разом вводить один и тот же код. Рекомендую обратить внимание на Zen-Coding. Вы можете сделать тоже самое при помощи Шаблонов ReSharper-а или Сниппетов Visual Studio, лишь установив соответствующие плагины. Помимо этого, искусство настройки Visual Studio — это то, чему Вы должны обучиться.

6. Оборачивайте все ссылки в Url.Content или Url.Action


У Вас есть веб-приложение, в котором осуществляется навигация по страницам, вызов веб-сервисов, ссылки на javascript и CSS. Типичный проект. Все эти ссылки должны быть обернуты в Url.Content или Url.Action helper-ы. Это решает ряд типичных проблем при тестировании или развертывании приложения. К примеру, Вы тестируете приложение на localhost:898989/, и Вам необходимо развернуть его на myserver/myapp/, при этом значительная часть ссылок перестанет функционировать. Использование Url.Content и Url.Action решают эту проблему, поэтому я всегда их использую.

7. Возьмите на вооружение Частичные Представления (Partial Views) в связке с Ajax запросами


Частичные Представления — это Представления, которые не имеют master page-й и тэгов html и body. Они могут использоваться как в других представлениях на сервере, так и в Javascript на клиенте. В JQuery есть отличный метод $.load, который выполняет запрос на указанный url и затем вставляет в страницу полученную html-разметку. Это оказывается очень полезным в ряде случаев.

Иногда я пользуюсь маленькой хитростью — оборачиваю фрагменты разметки, которые долго загружаются в Частичные Представления. Затем, после загрузки страницы, я получаю данные из Частичного Представления (используя Javascript функцию setTimeout для вызова $.load). Таким образом, я получаю страницу, которая загружается быстро, при этом имеет все необходимые данные.

8. Заставьте Master page работать на Вас


Это не говорит о том, что изначально что-то не так с Master page, которая Вам предоставляется при создании проекта Asp.net MVC. Напротив, в 80% случаев, это именно то, что Вам нужно. Но как только я узнаю что должна делать моя главная страница, я убираю все лишнее из Master page. Так же, не стоит забывать о наследовании Master page.

9. Думайте о том, что необходимо дизайнеру


Даже если его нет. Это основной паттерн, которого я придерживаюсь. Я представляю себе дизайнера, который взяв чистый html и css, сможет сделать мой сайт гораздо привлекательнее. Это означает, что я использую чистый html везде, где это возможно, я пишу Javascript обработчики нажатия кнопки таким образом, чтобы они работали и с кнопками и ссылками (рекомендация: всегда возвращайте false, и как это я еще не написал для этого JQuery плагин).

10. Версионность css и Javascript


Это на самом деле тема моего следующего поста, но все же, затронем вкратце тему версионности css и Javascript. На самом деле это не специфика MVC, это стоит использовать во всех веб-проектах. Целью является решение проблем, возникающих с кэшем браузера. Вы знаете, что первое о чем Вы спрашиваете того, кто просит Вас о помощи — это очистил ли он кэш браузера. На мой взгляд, стоит установить автоматическое обновление версии сборки, затем присоединять номер версии в конец каждого Javascript файла. Выглядеть это должно соответствующим образом: «myapp/…/file.css?version=1.0.0.256». Так же, я использую добавление timestamp аналогичным образом.

Статься опубликована по просьбе товарища. К сожалению, сам инвайта подбросить не могу, поэтому желающие, могут выстать ему инвайт на почту dimaumen[at]ukr[dot]net.
Tags:
Hubs:
+15
Comments86

Articles

Change theme settings