Стив Макконнелл писал, что, согласно исследованиям, юнит-тесты помогают избежать меньшего числа ошибок, чем обзоры и инспекции кода. Так что, если вы думаете о том, что внедрить в вашей команде в первую очередь, подумайте о code review.
В примере из книги implementor представляет из себя абстракцию, предоставляющую сразу несколько стратегий. Потому меня удивило, что в описании моста ничего не сказано про стратегию.
Мне тоже не очень понравилась формулировка «отделение реализации от абстракции», новичка она может запутать. Поскольку читаю на русском, грешу на перевод.
Пройти 50 правил быстрее, чем сделать запрос к БД. Количество должно быть гораздо больше, чтобы издержки на запрос к базе стали меньшими, чем цикл по объектам в памяти. Едва ли у вас будет столько страниц.
Вы можете легко обновлять роутинг без перезапуска приложения.
RouteCollection реализует ICollection.
>То есть вы считаете, что указать пятьдесят правил в глобал.асакс — это хорошее решение?
>При таком подходе мы получаем необходимость править этот файл при малейшем изменении — это раз.
Не обязательно в global.asax. Вы можете придумать удобную абстракцию для заполнения RouteTable.
Смысл в том, чтобы таблица заполнилась правилами во время запуска приложения.
Если вам надо часто менять роутинг без релиза (в чем я очень сомневаюсь), вы можете вынести класс, заполняющий таблицу, в отдельную сборку, чтобы легко ее заменять на продакшн сервере.
>И я не уверен, что такая дикая таблица роутинга хорошо скажется на производительности —
>прежде чем добраться до дефолтного правила, надо пройти другие 50. Не могу утверждать, но
>есть мнение, что времени процессору придется потратить не меньше, чем на запрос к базе.
Могу утверждать, что запрос к БД медленнее, чем работа с памятью приложения. А еще при проблемах с доступом к БД ваше приложение даже не сможет узнать какое действие вызвать. Значит вы не сможете реализовать разную логику обработки этого исключения для разных действий.
>А рассмотренное решение — гораздо более гибкое.
Оно менее гибкое потому, что позволяет задать только контроллер, фильтр и один параметр.
В реальной жизни в урлах бывает больше параметров.
>Проблемы с доступом к экшнам — совсем другая тема. Надо рассматривать детально, навскидку
>вспоминается NonActionAttribute — хотя всё зависит от того, что и как вы хотите ограничить.
routes.MapRoute(
"helloworld",
"helloworld",
new { controller = "hello", action = "world" }
);
routes.MapRoute(
"Default",
"{controller}/{action}/{id}",
new { controller = "Default", action = "Index", id = UrlParameter.Optional }
)
/*
* имеем два урла для одного действия:
* /helloworld
* /hello/world
*/
Что значит «без возможности указать контроллер»?
Если это 50 ссылок на разные контроллеры/действия, то надо сделать 50 правил.
Вы просто переносите те же правила в БД. И у вас каждый раз будет лишний запрос к БД.
Не проще ли задать все правила при старте приложения, как это и предполагается?
routes.MapRoute(
"helloworld",
"helloworld",
new { controller = "hello", action = "world" }
);
routes.MapRoute(
"foobar",
"foobar",
new { controller = "foo", action = "bar" }
);
//...ваши 50 правил
routes.MapRoute(
"Default",
"{controller}/{action}/{id}",
new { controller = "Default", action = "Index", id = UrlParameter.Optional }
)
А еще я против дефолтного правила. Оно позволяет, при желании, вызывать любые действия любых контроллеров, зная их названия. Даже если для этих действий предназначены совсем другие урлы. Этого допускать нельзя.
Нужно было еще рассказать про LifetimeManager. Раз мы не используем new для создания объекта, то можем использовать уже созданный. И можем реализовать, например, синглтон таким образом.
Применимо к веб-разработке, нормальное именование переменных и методов и хорошая архитектура, в большинстве случаев, избавляет от необходимости комментировать код. Если бывает такой код, к которому хочется написать комментарии в духе «сейчас я постараюсь объяснить, что же делает эта не читаемая колбаса», то, в идеале, надо менять сам код.
Иногда только в рантайме можно понять, что необходима какая-то сборка. Ссылка на нее может быть в файле конфигурации. Например, если используется IoC-контейнер c XML-конфигуратором. Тогда сборка, содержащая необходимую реализацию какого-либо интерфейса, должна присутствовать в папке bin, хотя ее упоминаний в коде нет.
Жду заголовок «Искусственный интеллект на CSS3, без скриптов» ;)
Мне тоже не очень понравилась формулировка «отделение реализации от абстракции», новичка она может запутать. Поскольку читаю на русском, грешу на перевод.
Вы можете легко обновлять роутинг без перезапуска приложения.
RouteCollection реализует ICollection.
>При таком подходе мы получаем необходимость править этот файл при малейшем изменении — это раз.
Не обязательно в global.asax. Вы можете придумать удобную абстракцию для заполнения RouteTable.
Смысл в том, чтобы таблица заполнилась правилами во время запуска приложения.
Если вам надо часто менять роутинг без релиза (в чем я очень сомневаюсь), вы можете вынести класс, заполняющий таблицу, в отдельную сборку, чтобы легко ее заменять на продакшн сервере.
>И я не уверен, что такая дикая таблица роутинга хорошо скажется на производительности —
>прежде чем добраться до дефолтного правила, надо пройти другие 50. Не могу утверждать, но
>есть мнение, что времени процессору придется потратить не меньше, чем на запрос к базе.
Могу утверждать, что запрос к БД медленнее, чем работа с памятью приложения. А еще при проблемах с доступом к БД ваше приложение даже не сможет узнать какое действие вызвать. Значит вы не сможете реализовать разную логику обработки этого исключения для разных действий.
>А рассмотренное решение — гораздо более гибкое.
Оно менее гибкое потому, что позволяет задать только контроллер, фильтр и один параметр.
В реальной жизни в урлах бывает больше параметров.
>Проблемы с доступом к экшнам — совсем другая тема. Надо рассматривать детально, навскидку
>вспоминается NonActionAttribute — хотя всё зависит от того, что и как вы хотите ограничить.
Если это 50 ссылок на разные контроллеры/действия, то надо сделать 50 правил.
Вы просто переносите те же правила в БД. И у вас каждый раз будет лишний запрос к БД.
Не проще ли задать все правила при старте приложения, как это и предполагается?
А еще я против дефолтного правила. Оно позволяет, при желании, вызывать любые действия любых контроллеров, зная их названия. Даже если для этих действий предназначены совсем другие урлы. Этого допускать нельзя.
Можно начать с этого: www.asp.net/mvc/tutorials#Routing