![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Описание маршрутов для MVC-фреймворка
Проблемы описание маршрутов в ASP.NET MVC известны:
- это слишком многословное описание
- это строки и отсутствие проверки в compile-time корректности маршрута
- это отсутствие хелперов для генерации ссылок
Есть, правда, шаблоны T4MVC, предоставляющие статические хелперы для генерации url'ов по action'ам и доступа к разнообразным view. Однако, проблема со строками в маршрутах остается, проблема проверки соответствия параметров описанных в маршруте и параметров обработчика тоже.
Хотелось бы сделать нормально, чтобы было кратко, интуитивно понятно, с проверками в compile time. Я достаточно давно в фоновом потоке размышляю на этим вопросом. И пока у меня сформировался такой краткий список требований к DSL описания маршрутов:
- внутри строки маршрута должно происходить связывание имен
- необходимо иметь возможность указать слово ХТТП
- необходимы ограничения на связываемые имена (прямо внутри маршрута? отдельно?)
- необходим вывод маршрутов по контроллеру
- возможно, необходима группировка маршрутов по общей части пути
- необходимы параметры по умолчанию
- необходимы имена для маршрутов (опционально?)
Возможно, требуется что-то еще. Однако в силу малого опыта разработки веб-оперденей, я не могу составить полный список потребностей, которые надо покрыть возможностями данного DSL.
Я смотрел описание маршрутов в Django - не очень понравилось. В качестве ограничений регулярки, убивающие читаемость. Из плюсов, пожалуй, возможность "подключить" сразу группу маршрутов и именованные маршруты.
Глядел на описание в Play Framework. Описание достаточно краткое и лаконичное, но нельзя сказать, что богатое возможностями.
И, конечно, я смотрел, как сделано в Ruby on rails. Это, пожалуй, самая продвинутая система описания маршрутизации веб-приложения. Там есть все из моего списка и даже больше. Сложно сказать, насколько удобно оно на практике, но читать такие декларации маршрутов, мне не очень приятно (видимо, из-за непривычности синтаксиса Ruby).
Смотрел какие-то другие поделия, регулярно натыкаясь на описание маршрута, приклеенное к обработчику. Такого счастья точно не надо.
Самая большая проблема, пожалуй, RESTful routes. Идея, лежащая в основе, достаточно проста - есть некоторый набор HTTP Verbs и с их помощью можно отобразить один путь на разные методы контроллера, имитируя действия (CRUD) над объектом (ресурсом). При этом, сразу возникает желание иметь вложенные объекты. И для этого, требуются какие-то специфичные средства описания. Для ASP.NET MVC уже достаточно давно была сделана библиотека, позволяющая несколько сумрачным синтаксисом на лямбдах описывать подобные иерархии. Потом, c выходом четвертой версии фреймворка, оно вроде стало не нужно, поскольку WebApi сам генерирует маршруты. Правда, это не касается вложенных ресурсов. При этом видно, что в дочернем ресурсе происходит накопление параметров от всех родителей. В Ruby, как я понял, принято забирать параметры из словаря, для целей реализации проверок в compile time это подходит мало. Не знаю, существуют ли красивые решения.
По сути, хотел просто сформулировать свои мысли по этому поводу. Но, заодно, пожалуй, спрошу у читающих меня:
- есть ли фреймоворк, где описание маршрутов сделано идеально, который можно взять как пример?
- какие задачи должен решать dsl описания маршрутов, то есть чем вы пользуетесь часто, чем редко, чем хотели бы пользоваться, но не имеете средств?
- это слишком многословное описание
- это строки и отсутствие проверки в compile-time корректности маршрута
- это отсутствие хелперов для генерации ссылок
Есть, правда, шаблоны T4MVC, предоставляющие статические хелперы для генерации url'ов по action'ам и доступа к разнообразным view. Однако, проблема со строками в маршрутах остается, проблема проверки соответствия параметров описанных в маршруте и параметров обработчика тоже.
Хотелось бы сделать нормально, чтобы было кратко, интуитивно понятно, с проверками в compile time. Я достаточно давно в фоновом потоке размышляю на этим вопросом. И пока у меня сформировался такой краткий список требований к DSL описания маршрутов:
- внутри строки маршрута должно происходить связывание имен
- необходимо иметь возможность указать слово ХТТП
- необходимы ограничения на связываемые имена (прямо внутри маршрута? отдельно?)
- необходим вывод маршрутов по контроллеру
- возможно, необходима группировка маршрутов по общей части пути
- необходимы параметры по умолчанию
- необходимы имена для маршрутов (опционально?)
Возможно, требуется что-то еще. Однако в силу малого опыта разработки веб-оперденей, я не могу составить полный список потребностей, которые надо покрыть возможностями данного DSL.
Я смотрел описание маршрутов в Django - не очень понравилось. В качестве ограничений регулярки, убивающие читаемость. Из плюсов, пожалуй, возможность "подключить" сразу группу маршрутов и именованные маршруты.
Глядел на описание в Play Framework. Описание достаточно краткое и лаконичное, но нельзя сказать, что богатое возможностями.
И, конечно, я смотрел, как сделано в Ruby on rails. Это, пожалуй, самая продвинутая система описания маршрутизации веб-приложения. Там есть все из моего списка и даже больше. Сложно сказать, насколько удобно оно на практике, но читать такие декларации маршрутов, мне не очень приятно (видимо, из-за непривычности синтаксиса Ruby).
Смотрел какие-то другие поделия, регулярно натыкаясь на описание маршрута, приклеенное к обработчику. Такого счастья точно не надо.
Самая большая проблема, пожалуй, RESTful routes. Идея, лежащая в основе, достаточно проста - есть некоторый набор HTTP Verbs и с их помощью можно отобразить один путь на разные методы контроллера, имитируя действия (CRUD) над объектом (ресурсом). При этом, сразу возникает желание иметь вложенные объекты. И для этого, требуются какие-то специфичные средства описания. Для ASP.NET MVC уже достаточно давно была сделана библиотека, позволяющая несколько сумрачным синтаксисом на лямбдах описывать подобные иерархии. Потом, c выходом четвертой версии фреймворка, оно вроде стало не нужно, поскольку WebApi сам генерирует маршруты. Правда, это не касается вложенных ресурсов. При этом видно, что в дочернем ресурсе происходит накопление параметров от всех родителей. В Ruby, как я понял, принято забирать параметры из словаря, для целей реализации проверок в compile time это подходит мало. Не знаю, существуют ли красивые решения.
По сути, хотел просто сформулировать свои мысли по этому поводу. Но, заодно, пожалуй, спрошу у читающих меня:
- есть ли фреймоворк, где описание маршрутов сделано идеально, который можно взять как пример?
- какие задачи должен решать dsl описания маршрутов, то есть чем вы пользуетесь часто, чем редко, чем хотели бы пользоваться, но не имеете средств?