Pull to refresh

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

Я работаю с командой над несколькими 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 аналогичным образом.

Это перевод статьи. Ссылка на оригинал.
Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.
Change theme settings