я тоже думаю что модели

лучше чтобы модели занимались только получением и записыванием данных. В контроллерах вся логика именно взаимодействия с веб слоем (аналогично для консольных команд для работы с консолью), то есть получение данных и преобразование их во внутренний формат, а также отбражение результата в консоль или ХТМЛ в браузер. А всю бизнес логику приложения выносить в сервисы, в которых исключить любое взаимодействие с веб-слоем (сессии, куки, получение HTML) или консолью (stdin,stdout, stderr).

контроллер должен принимать/отправлять роутеру response/request и все, возможно еще какая-то промежуточная валидация, но эт не точно

сервисы говоришь

хмм

это ж уже не mvc?

model-view-controller-service

Привет, кто меня помнит

в вебе вообще нет mvc

Мне оч помощь нужна

в вебе вообще нет mvc

ну ты понял о чем я

Короче регулярка с модификатором i не работает то есть ловит слово с зависимостью от регистра

из за чего такое может быть?:(

да понял, но вот из за того что это упрощение совершенно другой модели и становится ясно что чисто следовать ей не получится

ну под view в пыхе наверное понимается пререндеринг шаблонизатора (пыха)

или что то такое, не знаю как точно назвать

Да не надо тут программировать - пример выше из доков...

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

Короче регулярка с модификатором i не работает то есть ловит слово с зависимостью от регистра

скинь регулярку

preg_match('/клан/i', $message->body) все просто блять тупо в строке найти это

strstr юзать не буду

нужна регулярка

ловится тока клан

Клан

не ловится

горит пиздц

сделай /iu

не читал все, но если есть возможность не использовать регулярки, то лучше их не использовать, ибо даже простые регулярки внутри жирные шоппц

+

не читал все, но если есть возможность не использовать регулярки, то лучше их не использовать, ибо даже простые регулярки внутри жирные шоппц

жирные - это как?

толстая реализация в zend2

жирные - это как?

ну там, ресурсоемкие например, они ж компиляются или чего там внутри делают

там же конечный автомат внутре

или как там оно называется нутыпонел

я всегда думал, что они как раз шустрые и эффективные в смысле ресурсов

лучше чтобы модели занимались только получением и записыванием данных. В контроллерах вся логика именно взаимодействия с веб слоем (аналогично для консольных команд для работы с консолью), то есть получение данных и преобразование их во внутренний формат, а также отбражение результата в консоль или ХТМЛ в браузер. А всю бизнес логику приложения выносить в сервисы, в которых исключить любое взаимодействие с веб-слоем (сессии, куки, получение HTML) или консолью (stdin,stdout, stderr).

о это норм

не

толстые должны быть контроллеры или модели?

никто

в сервисах должно быть все?

в сервисах должно быть все?

я пока так делаю, возможно расширю свою точку зрения когда Эванса рпочитаю

но это не скоро будет((

шо це за книга?

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

толстые должны быть контроллеры или модели?

толстым должен быть программист. это значит, что ему хорошо платят и он хорошо кушает

шо це за книга?

загугли ddd

ой не, не интересует пока)

до доменов еще далековато мне

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

ну тут холиварно

толстым должен быть программист. это значит, что ему хорошо платят и он хорошо кушает

несмешно,я из за этой пластины в плече стал малоподвижным и "слегка" набрал

модели могут и ничего не знать о хранение

тогда мы получаем православный orm

приходтися ходить со вятнутым животом

который правильный

котоырй data mapper))

толстым должен быть программист. это значит, что ему хорошо платят и он хорошо кушает

че ты тогда не толстый, а?

которая доктрина)

но из минуса мы можем потерять инкапсуляцию

ну доктрина имхо жуткий orm :D

приходтися ходить со вятнутым животом

доброе пожаловать в клуб )

слишком много всего делает и поддерживает)

че ты тогда не толстый, а?

я дофига толстый) килограм 10 лишних

зато мало маперов надо писать

его надо конфигурировать только уметь

что кстати сначала читать паттерны фаулера или ддд эванса

я вот дочитал чистый код сегодня

надо двигаться дальше

ERROR: S client not available

чистый код кстати классно написана

я вот дочитал чистый код сегодня

clean coder еще прочти

ну отчасти класснно...но 40 страниц кода в одной главе так себе удовольстие)

она про то как не быть мудаком, очень хорошая книжка

что кстати сначала читать паттерны фаулера или ддд эванса

фаулера

ддд очень холиварно

Эванса надо на ночь читать вместо снотворного

кстати вот хорошая книга но малоизвестная

--Kristopher Wilson - The Clean Architecture in PHP

но я из за ебучего инглиша так до конца не дочитал ее ни разу(

почему вы книги именно по пхп

Привет народ.

большая часть хороших книг не привязана к языку

там рассказывааетс как писать фреймворконезависимые приложухи и в конце пример как с зенда на лару проект переводится

и правила хорошего и плохого между языками примерно одинаковы

почему вы книги именно по пхп

потому что в пхп своеобразный ооп

да там от пхп ток название

не особо прям акцент на нем делается

потому что в пхп своеобразный ооп

что там своеобразного в пхп?

в ооп именно

как то не так наследование работает?

что там своеобразного в пхп?

перегрузка, например

перегрузка операторов нет в java например

self/static штуки

в пыхе ее никакой нет

или ты о чем?

я про методы

ну да перегрузки методов нет неприятно

да я понял

мне тоже хотелось бы ее

но можно именовать методы