ну ну.... А теперь представьте. Руководитель проекта или заказчик, говорит: хочу чтобы везде где есть комментарии в начале текста должно добавляться "Человек сказал:". (Задачу уточню технически: потребовалась именно оработка данных полученных из БД). И вы будете везде искать свои query.... При этом MVC для того и нужен, чтоб не пришлось ни чего искать.... Я тупо иду в модель и в методе получения данных из базы, обрабатываю данные, и, автоматом, где бы эти комментарии не использовались (на станице товра, на общей странице отзывов, на гавной, в рассылке, в rss), эти изменения появлялись.... В вашем случае это будет геморрой... Ну или таки вы переделаете на вариант в рамках MVC.
MVC ради MVC тоже не надо. Делать так как написано в учебнике да это хорошо для профана новичка, точно слишком плохо не сделает. Но тот кто понимает как работает и исполняется програмный код не будет городить лишней кучи кода. Для чего? Тут всё зависит от опыта программиста чем больше его опыт, тем чище будет код.
@Walk, главное, зачем вообще нужны объекты - это полиморфизм. На котором строятся все паттерны, в принципе. Вот смотри, приведу задачу. Задача немного бредовая, но заказчик мне реально поставил такую, так что тут всё правда. У заказчика куча интернет-магазинов, часть на Open Cart 1, часть на Open Cart 2, часть - на Joomla + VirtueMart. Плюс есть товары, которые в разных магазинах повторяются (т.е. при изменении цен в одном магазине надо на тот же процент изменить цену и в других). И вот он захотел, чтоб из типа CRM, которую я ему делал, можно было цены во всех этих магазинах менять одновременно. Как это было сделано с использованием ООП? Был создан абстрактный класс PriceChanger, получающий ссылку на экземпляр соединения с БД конкретного магазина У него абстрактный защищённый метод doChange, который должен выполнять конкретный запрос (паттерн "Шаблонный метод") Так же у каждого PriceChanger могут быть дочерние PriceChanger, для связанных магазинов (паттерн "композит") У priceChanger есть метод change, который вызывает у своего экземпляра doChange, и метод сhange у дочерних "ценоменялок" (2 часть паттернов "Шаблонный метод" и "композит") Классы OpenCart1Changer, OpenCart2Changer, JoomlaChanger реализуют непосредственную логику изменения в каждом из магазинов Есть немного жутковатый конфиг, который описывает всю иерархию (т.е. какие магазины главные, какие дочерние и т.п.) и класс PriceChangerFactory, которые по этому конфигу создаёт экземпляры Теперь ради чего всё это было. Вот код в контроллере, который обрабатывает изменения: PHP: foreach ($_POST as $changerName => $percent) { if ($percent == 0) { continue; } $changer = PriceChangerFactory::instance()->createChanger($changerName); $changer->change($percent); } Самое прикольное, что если сюда добавить магазины ещё на каком-нибудь движке, то я просто допишу ещё один класс (какой-нибудь WPCommerceChanger, к примеру), и больше мне ничего не нужно будет трогать.
Нет. Это у вас не достаточно опыта. Завтра команда PHP изобретет новый, более продвинутый и все. (ну или это будет круче реализовано на уровне БД). И такое бывало уже.
А теперь вы слышите звон там где не он. Вы читаете сквозь строки, или вообще не читаете что я пишу, как можно разговаривать с вами, если вы за двумя деревьями не видите леса. --- Добавлено --- нет просто вы не компетентный пых программист.
Нет. MVC это именно для того, чтоб код был более понятен. Если вы свой проект декларируете как MVC, то вновь прибывший должен будет понимать что это значит, а не разгадывать, что вам лично показалось более логичным на определенном этапе. --- Добавлено --- @askanim, не наступайте на старые грабли. Я на личности не переходил. Я может и не компетентный "пых программист". Но программирую на нем со времен когда вы в школу пошли, а программирую на прочих языках. Со времен когда, возможно, еще и ваши родители в ясли ходили... Так что думайте прежде чем пишите
Если программист (вновь прибывший) приходит в проект, должна быть документация к проекту (Если он где то писал свою логику), и в этом случае если её нет и ещё нет комментариев, он ну скажем очень плохой человек. --- Добавлено --- --- Добавлено --- То что вы что-то не понимаете или не знаете, не говорит что у меня не достаточно опыта. --- Добавлено --- Поэтому говорю вы не компетентны, как программист пыха.
у тебя к проекту есть такая документация? если нет то ты и есть тот самый "плохой человек". ибо то что творится у тебя в коде - это уже не MVC
@voral не надо писать програмный код ооп ради ооп или же mvc ради mvc, нужно писать так как будет оптимально и чистенько. Потому что чистый код по умолчанию оптимален и по умолчанию удобо юзабельный (Вот про что я вам тылдычу уже около часа, но вы на отрез впихиваете мне то что надо писать mvc ради mvc в строгом понимании... (А в строгом понимании чего? А где логику писать? А где место отдельным библиотекам? Где вообще должен храниться алгоритм (А вообще что такое mvc?))) Ну вот задайте себе эти вопросы и ответьте на них. Нету чистого вида mvc каждый пишет логику так как считает её наиболее оптимальной. Есть простой некий набор инструкций, но это не обязывает программиста писать именно точно так же. Если вы считаете что я не прав, аргументируйте более логично. В ваших словах логики столько же сколько в 2+2=5 --- Добавлено --- Да мне пофиг чего и как вы и где вы. Важно то что я сейчас вижу. Что в ваших словах логики не на грамм. --- Добавлено --- Вот это просто показатель того как классно вы читаете мои сообщения. Такое ощущение что вы вообще мои посты: либо не понимаете, либо не читаете.
Ну мы уже не один раз это проходили. Вы все видите по своему. Вы воспринимаете MVC просто как религию, которой можно следовать или не следовать, следовать частично и или полностью. У вас опыт работы, как я понимаю, вы один в "команде" разработчиков... А я работа ив одиночку, и в команде (разного "размера", наших и дальнего зарубежья). У меня есть опыт и просто понимание для чего MVC полезен. Понимание на опыте, проблемах и т.п... Зачем мне доказывать вам, то что вы не хотите сышать? У вас опыт "три года прогаю на пыхе"... Прогайте дальше, наступайте на те же грабли, что я когда то настпуал.. .Ваш лоб - что хотите то и делайте...
Думайте как вам угодно. Но вот ток давайте вы будете свою думалку аргументировать. --- Добавлено --- я воспринимаю её как справку, для начинающего а дальше уже как хотите.
а с чего ты взял что у тебя чистенько и оптимальненько? если у тебя отрабатывает бизнес-логика в контроллере, то как ты собираешься её, например повторно использовать? лежала бы в модели, можно было бы юзать и в других местах, а так как у тебя, хз.
мало наступали раз до сих пор сами прописываете на пыхе шифрование сами, а не пользуетесь DEFAULT от пыха
Блин... Вам все разжовывать надо? Я просто показал пример, реальный пример, такое уже было в истории (PHP видите ли развивается).... Придумают они завтра функцию check_password_super_ii() и все.... А шифрование на пыхе... Да легко... Представьте есть крутая система шифрования программноаппаратная разработанная под конкретный проект... Работать с ней через расширение PHP (надеюсь вы в курсе, что расширения для PHP можно самим писать, и, иногда, это бывает очень полезно)...
Да ну молодцы чё) Флаг вам в руки и барабан на шею а я доверюсь умным дядькам из ZEND И доверюсь вот этой фразе PHP: /*PASSWORD_DEFAULT - используется алгоритм bcrypt (по умолчанию с PHP 5.5.0). Обратите внимание, что используемый алгоритм может со временем меняться на более сильный, когда таковой добавляется в PHP. Соответственно и длина результата может со временем меняться. В связи с этим рекомендуется выбирать длину поля для хранения в базе данных более 60 символов (255 символов могло быть хорошим вариантом).*/
Мысли вслух. Программист в своем развитии проходит несколько стадий. При чем даже на самом высоком уровне ни один не скажет "Я знаю все". Начинается все с "чайник". Это не плохо, это нормально. Но вот дальше у чайника два пути: развиваться или стать "ламером". "Ламер" это уже очень плохо. Считает, что все знает; "давит своим опытом и знаниями". Хотя по сути все тот же "чайник". Чаще всего это тупик в развитии программиста...
Я не буду писать на обычных функциях, я сделаю это на фулл статике. А как мы уже обсуждали - фулл статика это не ООП. Лолшто? Простыни по 5000+ строк с которыми невозможно работать - одна из первых проблем, с которыми я столкнулся при написании своих велосипедов.
да согласен ужасно это. Есть даже фраза Сократа: я знаю что ничего не знаю https://ru.wikipedia.org/wiki/Я_знаю,_что_ничего_не_знаю
Например password_verify появился с версии PHP5.5. А до этого с паролями думаете вообще не работали? Да даже сейчас некоторые сайты работают на PHP5.3.. А уверены что в PHP11 не будет чего то другого?
не пойдёт. Опиши калесо полностью и отдельно, чтобы например вдруг у одной машины был разный диаметр колёс, ширина шины например, разновидность протектора разная. Всё до мелочей! Вот и попробуй описать это на ооп, а потом на процедурке и на статике. И если ты так не видишь разницу, то сделай сам для себя её. Напиши там и там, и увидишь наглядно
а вот это я считаю плохо. --- Добавлено --- а я не уверен что будет вообще php11 --- Добавлено --- Ну вот честно говорю хеш пароля проверяется у меня ток в одном месте при логине и всё. Через грёбаный один контроллер, и пока даже не представляю где он ещё юзаться будет. Если речь о проверке авторизован пользователь или нет, то там другое проверяется, а не пароль. --- Добавлено --- и если будут вдруг сомнения в Аутентификации пользователя, вывалю модальное окно которое заставит его подтвердить свой логин и пароль где опять же будет отправлен запрос на тот же контроллер который один... Так в какой класс мне это надо вынести и для чего, я вот не знаю в одном месте юзается... А тут бац надо зачем то лишних 15 строк написать зачем? А просто чтобы было... --- Добавлено --- Так лан, болтать это хорошо но надо и работать.
Это не важно. Просто есть конкретный факт. Что в языке периодически одни функции уходят, другие приходят на замену. А хорошие проекты существуют долго и переживают все это... Опытные себе соломку могут постелить. Понятно, что команды типа echo у их нет потенциального смысла менять, а вот в области криптографии все очень серьезно. Развиваются и мощности и алгоритмы.