классы мэнеджеры - это прямое нарушение SRP и запах процедурного программирования. Когда вы видите класс "UserManager" вы можете точно передать чем он занимается? Ну да, менеджит юзеров, а что это означает? И вы начинаете перечислять обязанности.
Суть ООП сводится к тому, что у вас есть объекты, хранящие состояние, и они могут только обмениваться сообщениями. Причем чем меньше аргументов - тем лучше.
Как упражнение - попробуйте предложить мне как сделать оформление заказа без единого класса менеджера, сеттеров, геттеров и прочего булшита? У вас есть только классы User, Product, Order и возможно OrderLine, который должен хранить некоторую информацию о продукте (хотя бы стоимость на момент оформления заказа) и количество заказанных штук.
контроллер не должен содержать логику приложения. Это если вас интересует "как правильно". Он содержит точки входа для UI (Http как правило), то есть тупо конвертирует http запрос в вызов метода какого-то объекта (не будем называть это моделью для упрощения), и формирует http ответ на основе каких-то данных (которые тоже запрашивает у какого-то объекта а не лезет сам)
я не достаточно компетентен что бы продолжать разговор, но да, докер с сетью не поможет и может усложнить дело. Но плюсы в нем есть.
> А если дебаг символы нужно убрать? Вы же не понесете их в прод?
тут опять же. Я имею дело с интерпретируемыми языками. И да, я несу в прод все что нужно для дебага просто в продакшене оно не подключается и просто висит мертвым грузом. Но если что я могу взять образ контейнера используемый на сервере, слить себе и дебажить. С дебаг символами и прочим - тут не могу ничего сказать.
> А что, если нужно управлять зависимостями (которые не для сборки, а для работы)?
все зависимости вшиты в образ. Ну во всяком случае я так делаю и в этом есть значительный профит. Один и тот же образ можно задеплоить на разные сервера, протестировать и потом кинуть дальше.
> Поэтому его не стоит лепить где попало.
я бы сказал что по другому. Не стоит думать что все проблемы решит докер, но если он не решает одну проблему из десятка ваших и вашей команды, не стоит от него сразу отказываться.
> Докер отлично помогает в простых приложениях только.
Ой ну ладно вам уже, больше похоже что вы бросаетесь в крайности. Мне как разработчику удобно работать с докером. Слил образ, поднял проект, все занимает пару минут. Если вдруг надо что-то админам подправить в инфраструктуре - пыщ пыщ и я просто сливаю новый базовый образ и продолжаю работать. Это удобно в большинстве случаев а не только в простых. Вопрос в том как вы организуете работу в команде и будет ли команде удобно. Я вполне допускаю вероятность при которой докер будет создавать больше проблем для команды.
1. я тут не особо сведущь, задач таких нет, но в последних версиях докера сетью можно крутить как хочешь да и судя по тому что удалось мельком нагуглить люди это как-то делают. Опять же я не сталкивался с подобными задачами в пределах одного контейнера. Обычно это все все же для всего хоста делается, или я не прав?
2. а зачем в случае с docker паковать что-то в deb/rpm? Вот честно? Я до перехода на docker тоже в deb паковал но профита в этом по сравнению с возможностью собрать образ я не вижу.
3. Не понял, зачем разворачивать контейнер в контейнере?
p.s. докер не решает всех проблем, во всяком случае приведенный вами первый пункт - я сильно сомневаюсь что стоит даже пытаться это решать как-то с докером. Я думаю тут просто задача включает больше чем докер) А вот два других кейса - мне сложно тут согласится.
p.p.s. Я использую докер не для изоляции процессов а что бы собрать образ, протестировать его и дистрибьютить между окружениями.
сервер при успешном логине генерирует токен и отдает клиенту. Клиент его хранит у себя и отправляет с каждым запросом. Сервер проверяет подпись токена на каждый запрос.
utyfua: еще в php до 7.1 был такой нюанс - когда у вас более 10К объектов и есть циклические ссылки - то тогда ужасно педалил сборщик мусора. Но это не только классов касается - просто ссылки в массивах так же педалить будут, просто это надо явно написать так еще.
1) память такая штука - она подводит.
2) да это понятно, но когда у вас функций под сотню - поверье, намного быстрее находить вещи когда вы знаете в каком файле смотреть а не "куда скролл крутить". Можно конечно по именам функций пробовать... но это такое. Тут повторюсь - если вам удобно - то значит нормально. Ну и вам должно быть удобно в долгосрочной перспективе (через месяц попробуйте чего найти).
utyfua: делаем require всего в каком-нибудь autoload.php. Пусть opcache все тупо закэширует и пусть код все время лежит в памяти. Что бы интерпритатор не лазал на файловую систему на каждый запрос и все такое.
include_once очень медленная штука. Подход когда у вас все инклуды будут прописаны в одном месте спасает. Это не очень явно с точки зрения управления зависимостями но в целом норм, особенно если мы функции выносим в нэймспейсы и делаем их use. Повторюсь - если вы что-то с нуля пишите - используйте php7, там это удобнее.
xmoonlight: APC? opcache же, с версии 5.5 APC уже нет.
Barmunk вот только не надо говорить что ООП это что бы "функции по классам раскидать". Да и зачем? подключили все файлики и opcache за нас все разрулил. Особенно если с composer-ом.
utyfua: Возможно вы не правильно их использовали? Накладные расходы на "классы" не такие уж и большие. Особенно в свете PHP7+. Зато ООП позволяет более грамотно построить систему, спрятать состояние и уменьшить сложность.
Просто никогда не говорите "никогда". Жизнь заставит. На процедурах с глобальным состоянием ничего сложного за адекватные сроки построить не выйдет.
1) какая разница? Код кешируется в opcache, количество кода не влияет на производительность. Важно что бы код можно было ооочень легко найти.
2) найти - это древовидная структура. Когда все в одном файле - у вас все будет так или иначе со временем в перемешку.
3) все что повторяется (именно в плане логики работы а не кода) - в отдельные функции. Много много маленьких функций со временем приведут вас к древовидной структуре проекта.
