Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

D>>>Если он это скажет как compile error, то всё хорошо.
G>>Не скажет, ибо не знает никаким образом, что запрос придет на /home/index

D>Ну и низачот, чё. А у меня — скажет, потому что в моём абстрактном классе Page, кроме абстрактоного метда service() есть ещё uri(params: (String, String)*) (в реализациях по желанию добавляются overloaded статически типизированные uri(ParamObject)), и если хоть одна страница на данную ссылается, она вызывает её uri() для генерации ссылки, и ссылку на несуществующую страницу я при такой модели не пропущу. Про метод checkRights() я уже говорил... А в рамках вот этого повально популярного идиотизма с методом-на-URI вместо класса-на-URI такое не сделать, разве что ввести очередное naming convention типа Index_CheckRights, Index_URI и т.п. Которое, впрочем, компилятором опять же не проверится, так что один хрен низачот. Это раз.
Ну в ASP.NET MVC с первых версий есть хелперы, которые позволяют писать так:

Html.ActionLink<CatalogController>(c => c.Product(id))

И в разметке появится ссылка /Ctatalog/Product/{id}, ессено проверятся при компиляции. И для этого вовсе не надо контроллеры нагружать генерацией ссылок.

Да и не очень понятно зачем uri в классе Page, это ведь надо инстанцировать Page для получения ссылки.


D>Во-вторых, хрен отличишь обычный метод от HTTP-замапенного. В спринге это решается очередной <матерно>аннотацией</матерно>. Точнее, сразу несколькими (на класс, на метод, на параметры). В общем, утяжеляется всё сразу и резко.
В MVC по умолчанию работают соглашения, но при желании можно обвешать все атрибутами. Это смотря что тебе удобнее.