MVC Best Practices | Вы встраиваете свои ссылки в Url Helper?

Question

Просто прочитайте пост о лучших практиках MVC . В нескольких частях поста описано создание вспомогательных методов для связи с действиями на контроллерах. Вот клип:

1) Создайте методы расширения UrlHelper для генерации вашего URL из Маршрут

Избегайте прохождения контроллера, действие или имя маршрута в виде строки, создать методы расширения UrlHelper, которые инкапсулирует его, например:

public static class UrlHelperExtension
{
    public static string Home(this UrlHelper helper)
    {
        return helper.Content("~/");
    }

    public static string SignUp(this UrlHelper helper)
    {
        return helper.RouteUrl("Signup");
    } 
}

Я могу видеть, как это сократит ссылки, используемые в представлениях ... но я не вижу, как это "лучшая практика" Возможно, я просто что-то упускаю. Должен ли я сделать это, чтобы построить свои ссылки? Есть ли у этого преимущества, которых я просто не вижу?

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

Answer 1

Я, вероятно, не сделал бы этого, если бы маршрут не упоминался в нескольких местах. Я вижу смысл в этом, и я реализовал расширения HtmlHelper для добавления таблиц стилей, а javascript включает возможность использовать «версионные» ссылки, но мои общие ссылки включены как ActionLinks в UserControl (меню) и для большинства В других случаях я использую ActionLink или BeginForm / AjaxForm для ссылки на действие. В некоторых отношениях создается ощущение, что создание новых методов для всех, но чаще всего повторно используемые ссылки, добавляет сложность за очень небольшую ценность - такую ​​ценность, которую вы получите от простого ручного тестирования вашего пользовательского интерфейса, которое вам придется сделать. в любом случае.

Answer 2

Если кто-нибудь еще наткнется на этот старый пост, я бы предложил использовать шаблоны T4MVC Дэвида Эббо: см. его последнее сообщение в блоге здесь .

Answer 3

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

Answer 4

Если вы допустили ошибку при записи URL-адреса в виде строки, он не будет перехвачен до времени выполнения. Таким образом, попытка сослаться на маршрут, который не был создан как метод расширения, создаст ошибки во время компиляции, которые вы можете быстро исправить (даже раньше, если вы используете Visual Studio). Если вы обнаружили ошибку в том, как вы сформулировали маршрут, вы должны исправить ее только в одном месте.

Хотя вместо того, чтобы загромождать ваши UrlHelpers методами расширения, может быть лучше иметь статический класс, называемый чем-то вроде CommonUrls, который содержит статические свойства только для чтения (или статические методы, если вы предпочитаете).

РЕДАКТИРОВАТЬ: Я только что понял, что вам нужно будет передать экземпляр вашего UrlHelper в класс CommonUrls. Дурак я. В этом случае методы расширения, вероятно, являются правильным инструментом для работы.

Answer 5

Я использую этот подход. Это очень полезно, когда карта вашего приложения подвергается изменениям. И да, вам нужно много таких (у меня в классе расширений 1800 строк с комментариями)

Основное отличие, в моем случае, я строю URL, используя строго типизированный компоновщик. Это выглядит так:

    /// <summary>
    /// To campaign 'transfer credits' page
    /// </summary>
    public static string ToCampaignTransferCredits(this UrlHelper helper, int? idCampaignSource)
    {
        return To<CampaignController>(helper, c => c.Transfer(idCampaignSource));
    }

Я думаю, что это очень хорошая практика (ИМХО) по некоторым причинам:

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

Answer 6

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

Далее, в какой момент вы останавливаетесь? Для сайта любой сложности вам понадобится много таких помощников.

Я использовал несколько похожий подход при обращении к таблицам стилей, javascript, favicons и т. Д., Хотя я использую HtmlHelper, а не расширения UrlHelper, так как концептуально я думаю, что они больше подходят для этой задачи.

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