Комментарий к статье о «правилах разделения» превратился в небольшую отдельную статью, которая вновь доказывает, что разработка любого приложения сложнее Hello World требует обоснованных решений и творческого подхода, иногда опровергающего эти самые решения.



В своей статье, Рауф приводит MVC, как очень правильный шаблон проектирования использующий разделение ответственности. Я бы с этим не согласился, а первое хорошее шаблонное разделение, которое приходит мне в голову — Observer (наблюдатель).

На мой вгляд MVC, как и MVP (Model View Presenter) шаблоны мощные, но достаточно размытые. Это значит, что никогда нельзя провести четкую грань между M, V и C/P — т.е. без привязки к конкретному проекту никогда нельзя сказать, где кончается контроллер и начинается представление, или какой код мы будем писать в модели, а какой в контроллере.

Насчет веб/клиент-сервер/server-side+JS+AJAX я бы тоже не очень согласился с тем, что надо очень жестко делить логику и представление.

Дело вот в чем:

1. Опять же грани размыты — простейший пример все тот же проект продающих компьютеров-киосков в «Связной». Тут конечно играет роль специфика приложения (а я к тому и веду)! Вы хоть раз видели, чтобы корзина хранилась и обрабатывалась на клиентской стороне ( в браузере ), а запоминалась на серверной стороне, только в конце пути — после нажатия кнопки «Заказать»? У нас именно так.

2. Снова о размытых гранях и все том же оффлайн-веб-приложении(да да, я НЕ опечатался). В приложении достаточно много client-side кода, а Javascript — язык специфичный (коллбэки, замыкания, рантайм-расширения). Кое-где приходится использовать мега-хаки, привести в порядок которые, лично мне не представляется возможным. Как бы вы например справились с ОТЛОЖЕННЫМ ренедерингом в Chrome/Chromium ??? О том, когда и как Chromium рендерит лениво/отложенно планирую отдельную статью.

Так вот — данные вытягиваются при помощи AJAX с сервера — их бы получить в JSON, и рендерить уже на клиенте… Не тут-то было — специфика приложения диктует отдавать не JSON, а HTML — иначе тормоза и снова упираемся в отложенный рендеринг.

3. DOM-Model, CSS и Javascript достаточно тесно связаны между собой. Некоторые вещи хотелось бы сделать при помощи чистой разметки, например плашки с округлыми рамками и тенями — картинкой, однако оказывается, когда их много — начинаются тормоза и приходится использовать CSS3 (нам проще — у нас только Chromium). Для анимации хотелось бы использовать CSS3-Animation, любезно предоставленный движком WebKit, однако практика показывает, что он тормозит требователен к ресурсам.

Итог по DOM+CSS+Javascript+AJAX:

На реализацию сильное влияние оказывают технологии и ширина канала. В итоге часто приходится делать не так, как красиво, а так, как будет хорошо работать. Ну и получается, что говнокод и костыли рулят, как бы сильно меня самого это не удивляло…

Но давайте вернемся к MVC… Хотелось бы сказать, что злоупотреблять им совсем не стоит. Возьмем к примеру простейший говносайт-визитку, которых я в свое время наплодил десятка два.

Как обычно на каждой странице мы имеем сайдбар с новостями. Вот где возникает дилемма и ребро между Controller и View становится мягким…

К делу! Хорошо бы сделать выборку коллекции из пяти последних новостей в контроллере, но лично мне это не нравится по одной простой причине — это придется делать в каждом (почти) контроллере.

Опытный ООПэшник :) скажет, что надо выделить родительский класс CommonController с методом fetchLastNews, который будет запускаться каждый раз непосредственно перед исполнением основного *Action. Не тут-то было!!! Представим, что это не просто пять последних новостей, а некоторая достаточно тяжелая выборка ( и кэширование нам никак не катит ), да еще ко всему используются эти новости лишь на 65% страниц. Наследовать контроллеры от разных базовых классов??? БАРДАК!!! (IMHO)

Но изящный костыль выход есть, если вы имеете шаблонизатор с простым исполнением PHP-кода ( как дела обстоят в других языках я представляю пока слабо) — я обычно использую Macro из limb-project.com или native-php (Smarty хоть и подходит, но исполнение кода в нем мне не нравится {PHP} ЖЕСТЬ {/PHP} )… Так вот, если вы имеете хороший PULL-шаблонизатор — лучше сломать в этом месте грань V|C и сделать выобрку новостей в подшаблоне, который в любой момент может быть подтянут в любой шаблон/Layout инструкцией Include.

Я уже предвижу летящие в меня помидоры от привеженцев MVC ( а я его тоже люблю), но статья призвана не опровергнуть его мощь, а лишь подчеркнуть размытость компонентов, дабы предостеречь разработчиков, видящих в MVC серебрянную пулю.

Серебрянной пули нет — есть золотая середина, но Вам (да и мне) еще предстоит ее найти.