skyANAspв общем я решил использовать для грида обычные модели, только недокармливать их, чтоб не такие жирные были :)
а остальные вьюхи снабжать полноценно оформленными моделями, а то с вашими вьюмоделями на клиенте сильно не разгонишся!Вы статью-то прочитали? :)
В какой-то момент (по готовности окна к примеру) Ваш грид (вью) генерирует событие "Загрузите список того-то".
Контроллер подписан на это событие и дёргает модель (к примеру метод list);
Модель запрашивает сервер (или что там у Вас);
Перед загрузкой данных модель генерирует событие "Список загружается", Вью подписано на это событие и отображает к примеру гифку с крутящимися шариками и надписью "Wait";
Модель получает данные от сервера в виде JSON (полный он у Вас, или нет - это Вам решать) и генерирует событие (или дёргает обсёрверы как в статье) куда и передаёт полученные данные;
Вью обрабатывает событие "Список загружен", в аргументах которого JSON, выполняет рендеринг, снимает гифку с шариками.

Далее пользователь тыкает на определённую строку, открывается другое Вью, что генерирует событие "Загрузите-ка мне запись по идентификатору", если у Вас JSON не полный;
Контроллер ... и дёргает модель (уже метод getItem(id));
Далее тот же контур, только события и реакции другие...

Т.к. мы ничего не кэшировали, то модели остались стройными :) И где тут наши вьюмодели, что Вас тормозят?

Прочитал - статья слабенькая. У автора хромает теоретическая подготовка и знание JavaScript

МСУЛичное мнение: MVC на Javascript - по меньшей мере параноя.

Это вы зря - самый сильный тренд в наше время

МСУ1. Параноя в том, что js - это динамический язык без типизации.

-это кстати можно и в плюс огромный занести, а строгость типов можно уже давно обеспечиаить при помощи defineProperty

МСУ2. Параноя в том, что клиент легко и непринужденно поддается атаке. И строить бизнес-логику на js - самоубийство.

- бизнес логику никто на клиенте не строит- только поддерживает гуевыми распорками и валидаторами ввода

МСУ3. Адекватные люди строят слабое связывание в случае rich интерфейса и не в случае rich интерфейса - на сервере.
-тут возразить нечего :) но это никак не относится негативно к клиентсому МВЦ :)
МСУ4. Так же не забываем про рефакторинг кода.
-хорошие паттерны и правила - помогут избежать проблем :)

да и веяние нынче верное -
гуи -для клиента
руление данными - для сервера

и сервер свободен от построения гуевин и люди довольны скоростью и отзывчивостью приложений

skyANAspПрочитал - статья слабенькая. У автора хромает теоретическая подготовка и знание JavaScriptУ канадца тоже? :)
А как Вы в итоге реализовали у себя MVC?

я пытаюсь построить комплекс на базе Backbone.js - легкий, ненавязчивый и гибкий - ни в чем не ограничивает разработчика, но снабжает его удобным каркасом МВ....
На клиента динамически грузятся сущности (классы моделей, видов и коллекций) и выполняются
Рулится все конфигом прав и организации интерфейса на сервере БД - весь конфиг грузится в виде JSON
естественно что клиенту никто не доверяет и все данные и права перепроверяются на сервере БД перед выдачей и получением

МСУ,

вы конечно можете плыть против течения, но ктож вам будет виноват :))

skyANA,

мы тоже пытаемся строить Saas :)
разделение нагрузки сильно снизит затраты на облачный сервис!

skyANA,

а использование ASP.NET MVC в облаке - только на руку держателям облака - куча бабла им на халяву :)

skyANA,

наш предыдущий проект был спроектирован как предлагает МСУ - куча виджетов jQuery и куча говно-кода, который постоянно рос и все больше и больше фолил - потому как некогда было времени потратить на разработку архитектуры - давай, давай, а не то уволим!

Намучались - решили сейчас спроектировать нормальную архитектуру

МСУP.S. Чем Ваша цмс лучше DNN, у которого есть бесплатная редакция с огромным комьюнити по всему миру?

Как ни странно - постоянно сталкиваюсь с заказчиками - у них есть доступ ко всяким таким DNN валяющимся по всему инету - но их почемуто это не устраивает -такой вот парадокс!