Укажите ASP.NET MVC 3 Routes символически - PullRequest
Новая
       5

Укажите ASP.NET MVC 3 Routes символически

0 голосов
/ 17 июля 2011

Мне очень нравится среда ASP.NET MVC 3.Или, по крайней мере, это несравненно лучше, чем пытаться дурачиться с ASP.NET 3.5 или 4.0.Тем не менее, я просто очень смущен чем-то.Почему они решили указать маршруты со строками?

IOW, мне сказали указать мои маршруты следующим образом (например): 

... new { controller = "Products", action = "List", id = UrlParameter.Optional }

Этот маршрут соответствует ProductsController.List ()метод.Допустим, у меня настроение рефакторинга, и я хочу переименовать мой ProductsController в InventoryController.После использования выбранного инструмента переименования я открыл Global.aspx, прошёл все мои маршруты и изменил все эти глупые строки на «Inventory».Вы можете ответить, что я могу найти и заменить ... но давай!Я чувствую, что это такой ответ последнего поколения.

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

Серьезно, хотяВариант будет отражением.Будет ли удар по производительности для этого?Я полагаю, что для получения моего ProductsController фреймворк MVC должен использовать отражение в этой строке «Products», так что ... Но вам также придется удалить часть «Controller» имени типа следующим образом: 

= typeof(ProductsController).Name.Replace("Controller", string.Empty)

Я мог бы использовать следующую вспомогательную функцию, чтобы сделать ее немного СУХОЙ: 

public string GetControllerName(Type controller)
{
    return controller.Name.Replace("Controller", string.Empty);
}

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

Есть ли какая-то причина, по которой не следует использовать следующий (логично?) шаг, и свойства контроллера и действия ожидают Типы и Делегаты непосредственно?Разве это не будет просто чище и яснее?Насколько я понимаю, фундаментальным аспектом MVC является соглашение о конфигурации, но маршрутизация с этими строками мне кажется лишь скрытой формой конфигурации.

Есть ли другой способ обойти это?Я все еще новичок в MVC.Я читал, что мы можем заменить эти компоненты маршрутизации.Кто-нибудь знает, возможно ли сделать то, о чем я говорю?И если это невозможно, хорошо ... я здесь один?Я что-то пропустил?Некая главная причина, почему важно, чтобы эти маршруты задавались немыми строками?Если нет, то может ли это быть чем-то, за что можно лоббировать?

Я один ненавижу это, когда строки используются таким образом?Я все еще думаю, что C # нужно что-то похожее на символы Ruby и ключевые слова Lisp, которые могли бы использовать наши инструменты рефакторинга.Вроде как «строковые перечисления», где имя значения перечисления является одновременно значением.

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

СпасибоДжеромейерс

1 Ответ

1 голос
/ 17 июля 2011

Лично у меня никогда не было проблем с определением маршрутов, потому что я всегда тестировал их .Поэтому, если у меня настроение рефакторинга, мои модульные тесты всегда гарантируют мне, что маршруты будут работать так, как я хочу.

Конечно, если вы все еще не удовлетворены тем, как команда ASP.NET MVC разработала структуру(не стесняйтесь открывать заявку и голосовать за улучшения в будущих версиях) вы всегда можете написать собственный маршрут: 

public class IHateMagicStringsRoute<T> : Route where T : Controller
{
    public IHateMagicStringsRoute(
        string url,
        Expression<Func<T, ActionResult>> expression
    ) : base(url, Parse(expression), new MvcRouteHandler())
    { }

    private static RouteValueDictionary Parse(Expression<Func<T, ActionResult>> expression)
    {
        var mce = expression.Body as MethodCallExpression;
        if (mce != null)
        {
            return new RouteValueDictionary(new
            {
                controller = typeof(T).Name.Replace("Controller", ""),
                action = mce.Method.Name
            });
        }
        return null;
    }
}

, а затем вместо: 

routes.MapRoute(
    "Default",
    "{controller}/{action}",
    new { controller = "Home", action = "Index" }
);

вы можете: 

routes.Add(
    new IHateMagicStringsRoute<HomeController>(
        "{controller}/{action}",
        x => x.Index()
    )
);

Теперь вы можете переименовывать свои контроллеры и действия так, как вам нравится.

...