>> сортировка, пэйджинг, всё это приходился делать в
контроллере
такой mvc действительно не нужен. потому что это не mvc, а какая-то фигня.
-~{}~ 24.02.09 07:47:
а вот пост Пилота меня даже несколько смутил, потому что он, в конечном счете, прав. Фреймворки нужны программистам, конечному пользователю совершенно по фигу на качество кода
я достаточно насмотрелся на фреймворки, писавшиеся месяцами, вроде бы в деталях продуманные, но при разработке на них они фейлились на совершенно обыкновенных по сути задачах -- сделать страницу, как на макете, с описанным поведением: хак на хаке получался. Спрашивается, зачем нам фреймворк, если его использование только все усложняет.
с другой стороны, достаточно беглого взгляда на код Пилотовского движка, чтобы убедиться, что design patterns все-таки офигенная штука.
(
pilot911, не обижайся
)
какой вывод можно сделать. Написать фреймворк, который заранее решит все проблемы, невозможно. Лучше всего его выделить впоследствии из грамотно написанного достаточно сложного проекта. И исползовать для других своих же собственных проектов. А универсальнвый фреймворк, который устроит всех, это утопия.
Фреймворком, кстати, я считаю "абстрактное приложение", расширяемое для реализации нужного функционала. А например ZF, или WACT, это скорее набор библиотек, способных при соответствующей обвязке образовать фреймворк. Так вот для задач, отличающихся от типовых, удобнее как раз последнее
Ну и опять же, не стоит все заранее пытаться спланировать. Не получится. Говнокодим, реафкторим, говнокодим, рефакторим - это нормальный цикл разработки.
Сумбурно чото получилось, но может мысль понятна.
-~{}~ 24.02.09 07:59:
А, и вот еще, самое важное то я упустил. Перейдем немножко в плоскость бизнеса, а точнее рассмотрим затраты на техническую сторону любого проекта. Затраты (немножко грубо, но для наших рассуждений достаточно такой точности) состоят из затрат на разработку и затрат на поддержку. Возьмем одну крайность, наймем индусов за еду, затраты на разработку будут невелики, но последующие затраты на поддержку этого кода превысят все возможные рамки, вплоть до полного переписывания. Такое, кстати, бывает в жизни, и после этого можно броситься в другую крайность. Нанять супер-дупер профи, помешанных на этом деле, и дать им полную свободу действий. Они сделают хорошую архитектуру, напишут замечательный код, но любой человек увлекается. Программирование это само по себе искусство абстрагирования, выделения общего. И этим можно заниматься бесконечно. Увлечься тут крайне легко, и получим мы мегауниверсальный фреймворк, потенциально решающий в сто раз больше задач, чем необходимо, за время разработки, на порядки превышающее действительно необходимое для решения изначальной задачи.
То есть, во всем нужен баланс. А баланс - именно затрат на разработку и на поддержку.
Ключ к успеху - своевременный рефакторинг. Индусы его делают позже, чем надо (или вообще не делают), увлеченные профи - с самого начала. И то, и другое - ошибка. Всему свое время
).