Комментарии 6
Если я правильно понимаю, то на клиенте мы имеем все роуты, которые сможет просмотреть пользователь через get (при желании)?
При использовании RouteJs на клиенте по умолчанию будут доступны все роуты, которые вы описали для приложения. Т.е. в данном случае вы пользуетесь методом Router.action() на клиенте, так же как @Url.Action() на сервере. Так же есть возможность выносить на клиент не все роуты, а только необходимые, помечая нужны экшены специальным атрибутом.
*Это я вслух думаю. Конечного идеального решения у меня в голове пока нет*
При том, что сам сталкивался с этой проблемой, мне кажется эти библиотеки решают не ту проблему.
Кмк, проблема не в том, как передать в яваскрипт аякс-урл а в том, что яваскрипт воспринимается, как небольшое дополнение к серверной бизнес-логике. Конечно, если на весь проект, единственный аякс запрос — это что-то вроде вернуть общее количество записей в БД, тогда можно и адрес метода в тег сгенирировать.
Но если в каждом контроллере есть хотя бы один аякс метод и к тому же к нему появляются параметры — стоит задуматься об комбинации аякс-апи / MVC-фреймворк. Сильно много времени это не заберёт, но во-первых, вынудит явно сформулировать интерфейс (REST например) на сервере и освободит клиент от жёсткой зависимости. Тот же Angular прекрасно умеет подставлять значения в запросы и все пути можно описать в одном месте.
Опять же это открывает дорогу для других клиентов (вот затребует клиент не только веб сайт, но и десктоп или вообще, мобильную апп).
При том, что сам сталкивался с этой проблемой, мне кажется эти библиотеки решают не ту проблему.
Кмк, проблема не в том, как передать в яваскрипт аякс-урл а в том, что яваскрипт воспринимается, как небольшое дополнение к серверной бизнес-логике. Конечно, если на весь проект, единственный аякс запрос — это что-то вроде вернуть общее количество записей в БД, тогда можно и адрес метода в тег сгенирировать.
Но если в каждом контроллере есть хотя бы один аякс метод и к тому же к нему появляются параметры — стоит задуматься об комбинации аякс-апи / MVC-фреймворк. Сильно много времени это не заберёт, но во-первых, вынудит явно сформулировать интерфейс (REST например) на сервере и освободит клиент от жёсткой зависимости. Тот же Angular прекрасно умеет подставлять значения в запросы и все пути можно описать в одном месте.
Опять же это открывает дорогу для других клиентов (вот затребует клиент не только веб сайт, но и десктоп или вообще, мобильную апп).
К слову, Ajax — это не обязательно JSON, могут загружаться куски уже сгенерированной на сервере страницы. Именно при таком подходе удобно использовать описанный подход.
А что касается Single-Page App (на Backbone, Angular, Ember, итд) — тут концепция немного другая. И тогда не нужно генерировать URL в data-* атрибут какого-нибудь тега, нужно передавать URL централизованно (что лучше) или же использовать какие-то соглашения, чтобы URL на клиенте «магическим образом» совпадали с роутами сервера (что хуже — ибо, на практике часто расходится и во многих случаях необходимо пойти немного в разрез каноническому REST, а также нельзя забывать про base-URL).
А что касается Single-Page App (на Backbone, Angular, Ember, итд) — тут концепция немного другая. И тогда не нужно генерировать URL в data-* атрибут какого-нибудь тега, нужно передавать URL централизованно (что лучше) или же использовать какие-то соглашения, чтобы URL на клиенте «магическим образом» совпадали с роутами сервера (что хуже — ибо, на практике часто расходится и во многих случаях необходимо пойти немного в разрез каноническому REST, а также нельзя забывать про base-URL).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ASP.NET MVC client-side routing