Вот в том то и дело, что инструмент. Только инструменты бывают разные и предназначены для разных вещей. Допустим вот это инструмент:
Очень полезная вещь, когда нужно быстро починить велосипед в дороге, дабы доехать до сервиса. И вот это инструмент:
который помогает сделать качественный ремонт. Глупо возить с собой такой чемодан, но столь же глупо в стационарных условиях пользоваться универсальным ключем.
Теперь без метафор, пример с кодом. Один из возможных вариантов развития событий. Допустим мы разрабатываем пресловутый "крутой проект". Со стороны разработки по вашей идеологии нужно использовать универсальный инструмент, дабы
Да, с одной стороны законное желание. Берем фреймворк и смотрим, как оно должно быть. К примеру академический вариант работы с юзерами. Нам нужны две страницы, использующие данные пользователя. Статистика там и кабинет допустим. По идеологии мы должны написать модель, в которой собрать максимум бизнесс-логики и два тонких контроллера (не особо смотрим на реализацию, тут чтобы всем понятно было):
userModel.php
class UserModel
{
public function getUserData($id)
{
$reader = $cmd->createCommand()
->select("*")
->from("{{user}}")
->where('id = :id', array(':id' => $id))
->query();
return $reader->readAll();
}
}
statController.php
class StatController
{
public function action()
{
$model = new UserModel();
$udata = $model->getUserData($this->user_id);
$this->render('office', array('udata' => $udata));
}
}
officeController.phpclass OfficeController
{
public function action()
{
$model = new UserModel();
$udata = $model->getUserData($this->user_id);
$this->render('office', array('udata' => $udata));
}
}
Красота. Однако посмотрим на это с другой стороны. Со стороны сервера и со стороны обслуживания проекта. А с этой стороны оптимальнее (какая крамола) вообще не делать модели:
officeController.phpclass OfficeController
{
public function action()
{
$reader = $cmd->createCommand()
->select("*")
->from("{{user}}")
->where('id = :id', array(':id' => $this->user_id))
->query();
$this->render('office', array('udata' => $reader->readAll()));
}
}
И второй аналогично.
Я прямо вижу, как сейчас передернуло приверженцев фреймворков. ФУ! Это же ТТУК!
Да. И менно. Только если взглянуть внимательно:
1. Сокращается количество используемых файлов, соответственно уменьшается количество обращений к ФС, увеличенюи скорости и экономии памяти.
2. Сокращается количество
задействованного кода. Как бы парадоксально не звучало на первый взгляд. Не написанного, а именно задействованного сервером. Что тоже плюс оптимальности.
3. Экономится память а запросах, так как теперь мы получаем только необходимые данные, а не универсально все.
4. Такой код намного ремонтопригоден. Объясню.
Во-первых все под рукой и не нужно бегать по файлам. Да, сейчас IDE минимизируют эти неудобства, но вспомним предмет дискуссии - они вынуждены делать этот функционал вслед за "развитием" технологий. Да впрочем и фиг с ним, все равно в одном файле удобнее.
Во-вторых. Представьте работу над этим проектом команды. Один человек модернизирует статистику, второй кабинет. Им одновременно потребовались изменения в модели. Получите конфликт. А если каждый занимается своим файлом - никаких проблем.
В-третьих. Допустим потребовалось изменить модель. А какому-то контроллеру это не понравилось. Имеем баг, так как налицо связанность программы. Дада, сейчас меня натычут носом в юнит-тесты. Однако вот как раз они то и нужны, чтобы избежать подобных ситуаций. А в случае с толстыми контроллерами этой ситуации впринципе быть не может.
Против этих доводов есть три железобетонных.
1. Если понадобится что то изменить во всем приложении, придется менять во многих местах. К примеру добавить еще один параметр к юзеру.
2. Раз нет модели, значит очень сложно использовать этот функционал в другом приложении
3. Много повторяющегося кода, что вредит скорости разработки.
Два последних опускаем сразу. Мы же рассматриваем "крутой" проект. А это значит он должен быть чуть ли не единственным в своем роде. Вряд ли кто то в трезвом уме и при памяти откроет свои сорцы конкурентам. А скорость разработки тут не главное, тут главное ремонтопригодность и способность к модификации.
Остается первый пункт. А вот тут то как раз и вступает в силу индивидуальная архитектура. В таких критических местах можно и модель сделать, и библиотеку и всё, что душе угодно. На то он и крутой проект, чтобы сделать все круто для конкретного места, а не как приписывает фреймворк.
Есть еще один - квалификация программиста. Мол если фреймворк, то спеца найти проще. Это глупость. Если программист не умеет читать код, ему вообще грош цена. И нечего прикрываться фреймворками.
А вот теперь ответ на вопрос.
Граница там, где заканчиваются обязательства и появляется свобода действий.
waldicom не зря зачеркнул фразу про фреймворки. Есть новые технологии, которые действительно помогают делать крутые вещи, а есть идеология не изобретать велосипедов. Там, где последняя - стогнация и упадок. А по последним тенденциям приверженцев унификации становится все больше. Не удивительно, это проще. Как говорят - программист дороже железа. Только так говорят разработчики. А те, кто потом обслуживает это все, зачастую думают иначе. В противном случае потребитель получит и дорогое железо и дорогого программиста.
А в итоге он возьмет какую-нибудь новоиспеченную джумлу или вордпресс и успокоится. А программист из дорогого превратится в нищего)))
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
) себя, так: