Asp.net Mvc: Мои Правила Для Представлений

Я работаю с командой над несколькими проектами ASP.NET MVC с октября 2009 года.

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

ASP.NET MVC, как и любую новую технологию, можно использовать плохо, и имея неудачные примеры, мы всегда стараемся сделать код лучше, выбирая оптимальные варианты реализации задач.

Для начала давайте подумаем о задачах Представления, его основная функция — вставка данных в HTML. Это правило исключает неточности — не получать данные, не передавать данные, а просто вставлять данные в HTML. И, честно говоря, это довольно сложно.

Подход, которому я всегда стараюсь следовать, заключается в создании разметки страницы (aspx), максимально похожей на результирующий HTML. Основная причина такого подхода — приблизить исходную разметку к итоговой, исключив тем самым двойную работу.

Я хочу видеть «div» в исходной разметке и быть уверенным, что «div» также будет в результирующем HTML.



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

Например, простой цикл «for» для создания таблицы или цикл «if» для отображения функций администратора, но вам не следует определять формат даты и времени или анализировать строки — это то, что модель должна делать для представления.

Сделайте приблизительный расчет: если вы видите больше кода C#, чем HTML, значит, вы сделали что-то не так.

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

Храните JavaScipt в отдельных файлах.



2. Используйте типизированные представления
Это справедливо для всех представлений, в которых вам необходимо передавать данные из контроллера в представление.

Создайте модель представления для представления и передайте данные через модель.

Это открывает перед вами целый ряд возможностей, например, типизированные HtmlHelpers. В результате я очень редко использую модель представления между представлениями или даже действиями контроллера.

Я делаю отдельные модели для GET, POST и DELETE. Чем больше тем лучше.



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

Да, это не лучший способ реализации Views, на первый взгляд. Если вы сделаете ViewModel слишком общим, вам придется реализовать в представлении много логики для передачи данных.

Ключевым моментом является то, что данные в модели служат представлению, поэтому вся работа по получению данных в правильном формате должна выполняться при передаче данных в модель.

Я всегда имею это в виду, особенно когда Модели необходимо определить классы CSS для элементов html. Как же во Views у меня гораздо больше, чем данные из базы.

Примечание.

Когда использование модели представления станет популярным и данные будут адаптированы к представлению, AutoMapper станет очень популярным.



4. Собственные HTML-помощники — замечательная вещь
Создать свои собственные HTML-помощники очень просто, и как только вы научитесь это делать, вы поймете, что они замечательные.

Это простой способ инкапсулировать некоторую логику и удалить ее из представления.

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

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

У меня в проекте есть несколько мест, где мне приходится менять разметку в зависимости от используемого браузера, для этого я создаю Html Helper, который определяет браузер.



5. Стандартные помощники HTML — это здорово, но не забывайте про HTML.
Цель этого правила — понять, какую разметку создают стандартные помощники HTML. Несмотря на всю полезность HTML-помощников, у них есть и некоторые недостатки (любые модификации атрибутов «имя» или «значение» очень неприятны).

Иногда гораздо проще заменить их стандартным HTML (особенно вводом), чтобы получить более предсказуемый результат. В качестве бонуса это облегчит понимание вашего кода новому сотруднику.

На данный момент я использую 50/50 HTML Helpers и HTML. Использование стандартных элементов HTML или помощников HTML является довольно рутинной задачей.

Вы вынуждены вводить один и тот же код снова и снова.

Рекомендую обратить внимание на Zen-Coding. Вы можете сделать то же самое, используя шаблоны ReSharper или фрагменты Visual Studio, просто установив соответствующие плагины.

Помимо этого, вам нужно научиться искусству настройки Visual Studio.

6. Оберните все ссылки в Url.Content или Url.Action.
У вас есть веб-приложение, которое перемещается по страницам, вызывает веб-сервисы, ссылается на JavaScript и CSS. Типовой проект. Все эти ссылки должны быть обернуты хелперами Url.Content или Url.Action. Это решает ряд распространенных проблем при тестировании или развертывании приложения.

Например, вы тестируете приложение на localhost:898989/, и вам нужно развернуть его на myserver/myapp/, и значительная часть ссылок перестанет работать.

Использование Url.Content и Url.Action решает эту проблему, поэтому я всегда их использую.



7. Используйте частичные представления в сочетании с запросами Ajax.
Частичные представления — это представления, у которых нет главной страницы, тегов HTML и body. Их можно использовать как в других представлениях на сервере, так и в Javascript на клиенте.

В JQuery есть отличный метод $.

load, который выполняет запрос по указанному URL-адресу, а затем вставляет полученную HTML-разметку на страницу.

Это оказывается очень полезным в ряде случаев.

Иногда я использую небольшую хитрость — заворачиваю в частичные представления фрагменты разметки, которые долго загружаются.

Затем, после загрузки страницы, я получаю данные из частичного представления (используя функцию Javascript setTimeout для вызова $.

load).

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



8. Заставьте главную страницу работать на вас
Это не означает, что с главной страницей, которая предоставляется вам при создании проекта Asp.net MVC, что-то не так.

Наоборот, в 80% случаев это именно то, что вам нужно.

Но как только я знаю, что должна делать моя главная страница, я удаляю с нее все ненужное.

Также не забывайте о наследовании главной страницы.



9. Подумайте, что нужно дизайнеру
Даже если его там нет. Это основной шаблон, которому я следую.

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

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



10. Управление версиями CSS и Javascript
Собственно, это тема моего следующего поста, но все же давайте вкратце затронем тему управления версиями CSS и Javascript. На самом деле это не специфично для MVC, его стоит использовать во всех веб-проектах.

Цель — решить проблемы, возникающие с кешем браузера.

Вы знаете, что первое, что вы спрашиваете у человека, обратившегося к вам за помощью, — очистил ли он кеш браузера.

На мой взгляд, стоит настроить автоматическое обновление версии сборки, а затем добавить номер версии в конец каждого файла Javascript. Это должно выглядеть так: «myapp/…/file.cssЭversion=1.0.0.256».

Кроме того, я использую добавление метки времени аналогичным образом.

Статья опубликована по просьбе друга.

К сожалению, я не могу сам дать ему инвайт, поэтому желающие могут отправить ему инвайт на dimaumen[at]ukr[dot]net. Теги: #ASP.NET #asp.net mvc #ASP #ASP

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.