Эвристика для разделения интерфейсной и серверной логики в библиотеках, таких как backbone.js.

«Классический» способ сделать Модель — Представление — Контроллер состоит в том, чтобы иметь все три на сервере. Затем браузер визуализирует выходные данные уровня просмотра HTML и некоторых JS.

Rails — отличный тому пример.

«Новый крутой» способ — рассматривать браузер как основной вычислительный движок, а внутренний сервер предоставляет services через API.

В этом случае программное обеспечение Model, View и Controller запускается (как Javascript или coffeescript) на клиенте. Backbone часто является частью решения на стороне браузера, но у него есть альтернативы, такие как Spine, angularJS и другие.

На внутреннем сервере вы запускаете СУБД и хорошую систему API. На Ruby/Rack создается несколько хороших фреймворков. См. сообщения Дэниела Дубровкина на code.dblock.org. Здесь у вас есть много вариантов.

Преимущества MVC для клиента

• Отзывчивый пользовательский интерфейс для пользователя
• Крутые одностраничные эффекты Ajaxy
• Одностраничные веб-приложения могут предоставить пользователю гораздо более быстрый пользовательский интерфейс, чем обычные веб-сайты.
• Хорошая архитектура, инструмент для создания приложений для iPhone/Android.
• В зависимости от приложения может использоваться для создания автономных веб-приложений, которые работают без подключения к сети.
• Это то, что многие крутые дети делают в эти дни

Недостатки

• Необходимо определиться с подходом для старых браузеров, IE и т. д.
• Сделать контент доступным для поисковых систем может быть непросто. Может потребоваться теневой веб-сайт только для поисковых систем
• Тестирование может быть проблемой. Но обратите внимание на новые библиотеки, такие как AngularJS, которые ориентированы на тестируемость.
• Этот подход включает в себя больше программного обеспечения: требуется больше времени для написания и тестирования.

Выбор

Тебе решать. Решение зависит от ваших временных рамок, ресурсов, опыта, потребностей и т. д. Нет необходимости использовать магистраль или что-то подобное. Это компромисс (см. выше). Всегда будет быстрее / проще не использовать его, но без него (или аналогичного) может не достичь ваших целей.

Вы можете создать отличное приложение MVC, используя только Rails или PHP с дополнительными библиотеками или другими решениями MVC.

Я думаю, вы правильно используете слово эвристика в непрограммном смысле? т.е. вы используете это, чтобы означать что-то вроде «эмпирического правила»?

Как правило большого пальца:

• Вы хотите, чтобы сервер отображал начальную загрузку страницы по причинам UX и SEO.
• Вы также можете иметь последующие частичные загрузки страниц AJAX, отображаемые сервером по тем же причинам. Профилируйте, чтобы увидеть, что быстрее: когда сервер обрабатывает и передает дополнительные данные (разметку) по сети, а не отправляет более сжатую полезную нагрузку (с помощью JSON) и передает ее клиенту. Есть компромиссы, особенно если принять во внимание мобильные устройства, где, возможно, рендеринг на клиенте будет медленнее, но опять же есть мобильные устройства с более медленным интернет-соединением...
• Как и в любой клиент-серверной архитектуре: вы хотите, чтобы клиент выполнял действия, требующие быстрого реагирования на клиенте, а затем отправлял некоторую асинхронную операцию на сервер, выполняющий ту же задачу.

Вывод расплывчатый, но верный: все дело в компромиссах, и вы должны решить, что нужно вашим продуктам.

Первые две вещи, которые пришли мне на ум, были безопасность и поиск.

• Вы всегда захотите ограничить доступ для чтения/записи на сервере.
• в большинстве случаев вы захотите, чтобы ваши функции поиска были как можно ближе к данным.