systemaworking, если говорить проще. Принцип Open/Close работает на то что бы уменьшить количество времени которое потребуется программисту что бы понять где у него чего упадет в случае добавления/изменения/удаления функционала который у него был, с учетом того что рядом может сидеть его коллега который пилит задачу связанную с вашими обьектами но не фига не знающий о тех изменениях что вы вносите. В случае с ДТО - это вполне решиться доп атрибутом и сеттером и геттером. В каких то случаях возможно придется добавлять новый класс. Но ваш вариант когда у вас приходит новый человек ему дает задачу там создавать пользователя через очередь - и он начиная писать UserDTO в IDE и получает подсказки UserDTO, UserWithAvatarDTO, UserWithAvatarWithPenisLengthDTO, UserWithAvatarWithPenisLengthWithBallsCountDTO - ну мягко говоря еще хуже, даже не затрагивая тему а нахрена вам все предыдущие DTO - их не должно быть в системе ибо их использование приведет к некорректной работе.
systemaworking, выходные из UserRepository у вас как был UserDTO так и остался. Обьекты которые работаю с этим ДТО и не знают что у него появился новый аттрибут и новые сеттеры и геттеры - так и продолжат работать, вы ж старый функционал не трогаете. Что с ними случится? В этом то и заключается смысл всей этой движухи - добавлять функционал и тогда обьекты которые не знают или им не надо знать о новом функционал - будут работать попрежнему, потому что старый вы не затронули. А если вы начнете свой движ - с созданием новых классов ДТО под каждый чих то вообщем то такая интепретация этого принципа принесет вам ровно те проблемы от которых этот принцип должен избавлять.
Принцип open/closed не говорит о том что добавляя автар вы обязаны создавать новые классы. Он говорит что вы должны стремиться к тому что бы новый функционал появлялся через добавление нового кода - в том числе и новых методов, новых атрибутов класса. То есть если в UserRepositoryDTO допишите новый setter и getter setAvatar, getAvatar и новый атрибут avatar это будет вполне в рамках этого принципа.
maksutka777, я думаю стоит сделать перед запросом DB::enableQueryLog() и dd(DB::getQueryLog()); после. И взять за правило если запрос что то делает не то что вы хотите, смотреть что вообще за запрос выполняется.
Илья Т., ну количество изменений в своем максимуме будет равно количеству столбцов во всех таблицах. Учитывая что таблицы с тысячами колонок в реляционных базах в большинстве случаев вообщем то бэд практис - то опять же таки возвращаемся к тому что я сказал.
Илья Т., ну если у вас 10 таблиц оно может и норм. а если 2000 то задолбаетесь читать. А учитывая что выкатывание миграций на прод вообще процесс не тривиальный и какой нибудь не правильный альтер тейбл может подвесить вам здоровую таблицу на длительное время и приходится разбивать эти альтеры на несколько операций, а в терминальных случаях делать копию таблицы обвешивать триггерами и потом переименовывать и только разработчик знает чего и как в каком случае делать то получается ровно что я написал - для серьезных и больших проектов такой скрипт не применим, а для мелких проектов - чего геммороится можно руками
смутно представляю себе людей готовых запустить на большой базе скрипт непонятно кем сгенерированный. вот честно говоря сильно бы хотелось бы посмотреть на самоубийц. желательно дистанционно. а для мелких бд - смысл делать такой генератор?
This function is an alias for apache_request_headers(). Please read the apache_request_headers() documentation for more information on how this function works.
Алексей Яковлев, а эта картинка с ответом в браузере это на какой запрос? на options или на get? cообственно и почему у вас метод OPTIONS из allow выкинут?
