Честно говоря если бы не сообщили про 20 в разработке, возможно бы все сгладилось. Однако наблюдая код проекта, небрежность в структурировании и отсутсвие общепринятых стандартов - этот проект сложно будет привести в норму и 20 лет опыта к сожалению кажутся неправдой… не говоря о том, что поддержке php 7.4 остались считанные месяцы, а поддержка 8.0 должна истечь в следующем году.
Вашу разработку надо приводить к 8.1, начать декларировать и соответствовать общепринятому psr-12. А учитывая увиденное, это потребует не малых сил и вложений своего времени, к сожалению :(
А как быть при таком подходе в системах разделенных на модули? Когда есть отдельно модуль "пользователи" и отдельно модуль "новости", а тестирование по кейсу подразумевает первоначальное заполнение базы сидами. Особенно если у пользователей заранее есть роли, которые следует использовать, которые хранятся в БД и на роли так же созданы фабрики используемые в сидах?
Первая версия бесплатна и так же получает патчи, пользуйтесь, зачем вам вторая версия?
Вторая версия октября стоит 9 долларов в год для проекта или 150 долларов для компаний/партнеров с неограниченным кол-вом лицензий, странно, что целая компания не может позволить себе это.
Для управления одним прожектором, блок размером с сам прожектор. Да и UNO не на всю используется, nano, micro возможно лучше бы зашли для такой задачи?
Валидация типов зависит от вас. Если вы укажите параметру $name тип string, и в dto укажите declare(strict_types=1);
В этом и основная проблема, ошибки должны быть контролируемые. Фатальная ошибка от php это крайняя линия уже самого интерпретатора, а не приложения. То есть ошибок интерпретатора надо избегать, особенно если это данные которые приходят из запроса к серверу.
В этом и суть была, то что я могу скормить туда массив или объект любого класса, а ClassTransformer автоматически преобразует в нужный мне объект DTO.
Зачем нужна фабрика, если есть возможность пользоваться конструктором объекта инициализируя только объект DTO, без необходимости задействовать левый объект ClassTransformer?
Ведь у нас нет необходимости создавать разные DTO в один и тот же момент, слой приложения в которое передаете DTO ждет конкретное DTO, соответсвенно лучше создавать его сразу, минуя лишний слой ClassTransformer'a.
Я понимаю если бы в ClassTransformer была дополнительная логика, например по маппингу, что в принципе не надо, но сложной логики по факту там нет.
Можно без него, однако не вижу проблему все-таки добавить мелкий интерфейс. Бывали случаи, что дополнительно Request'ы приходилось проверять на наличие DTO метода, сделать условие по интерфейсу проще.
Честно говоря проблема spatie/data-transfer-object не совсем ясна?
> При такой реализации я не вижу особо профита использования, ведь я так же могу сам прописать new DTO() и заполнить параметры.
Суть DTO не только в заполнении, но и в том, что DTO должно передавать валидные данные между слоями. Инициализировать же объект с использованием конструктора передавая туда $request->valid() или через статичный метод transform промежуточного объекта трансформера — не играет особой разницы. В частых случаях, при работе с Request'ом во входящих параметрах контроллера, а контроллер должен быть последним слоем где используется Request объект — инициализацию DTO можно делегировать методу request'a объекта не забыв заранее создать интерфейс.
Пример:
class CreateUserRequest extend FormRequest implement GetterDTO
{
.....
public function getDTO(): DataTransferObject
{
return new CreateUserDTO($this->valid());
}
}
Что позволит сделать контроллер более простым:
class UserController extends Controller {
public function __construct(
private UserService $userService,
) {}
public function createUser(CreateUserRequest $request)
{
$user = $this->userService->create($request->getDTO());
return new UserResources($user);
}
}
Я не особо вижу профита в промежуточном объекте вашего ClassTransformer'a для DTO который в целом при такой реализации выступает своего рода фабрикой DTO, при этом не обязательно, чтобы объект был DTO ведь скормить ему можно все что угодно, при этом отсутствует валидация типов.
Спасибо за перевод!
Начал пользоваться OctoberCMS еще с беты, есть как сильные так и слабые стороны.
Один из весомых плюсов, весьма мощная и гибкая админка из коробки, что позволяет реализовывать банальные CRUD'ы и средние за весьма короткое время, для чего-то не стандартного так же все легко кастомизируется.
Конечно есть и минусы, в маркете не так много нужных плагинов, а на некоторые плагины весьма завышенная цена. Так же отсутствуют туториалы для редакторов и администраторов как в том же Bitrix или WP, но разок написав и передав клиенту, все в принципе решается.
Еще тем кто любит «чистоту» может не понравиться php код в административных шаблонах с форматом .htm.
Спасибо за ссылку не менее интересный проект. Надеюсь покрытие и правда долго прослужит. Ну или видимо как «на поставщика наткнешься», мой коврик стерся за 11 месяцев, причем края остались целыми, но по центру мышкой все протер :)
Весьма интересная затея.
EVO покрытие столешницы надеюсь съемное? иначе протрется мышкой и другими частями двигающимися по нему, нет желания менять его раз в год вместе со всей столешницей).
Какой сплав используется в раме, возможно есть ли возможность облегчить вес рамы или сделать более легкую модификацию, 10-17 кг все-таки многовато для крепления на стол, это еще без обвеса из мониторов, клавиатуры, пользователя.
Чем обусловлен выбор барашковых гайек для закрепления наклона столешницы? Они имеют свойство проскальзывать, врядли кто-то будет доставать ключ чтобы отрегулировать наклон каждый раз когда это необходимо, а затяжка с помощью рук «барашков», темболее металлических, не всегда эффективна (или мало каши ел, или болевой порог не позволяющий сильно затянуть рожки ибо пальцы болеть начинают), а при не эффективной затяжке, постоянно будут ослабевать стоит туда руки положить или со временем. Возможно стоит заменить на пластиковые фиксаторы с большей площадью с металлической гайкой в основании, чтобы можно было взять всей ладонью или хотябы обхватить (аналогично как в фиксаторы положения солнцезащитного козырька на дачных качелях :D), понадобится меньше усилия чтобы их расскрутить/закрутить.
Некоторые студии используют битрикс и делают свою обвязку на laravel в нем же, что вообще отдельное извращение)
Сам по себе БУС уже за свое время уже очень много вобрал легалиси, а об актуализации документации вообще молчу. Некоторые студии тянут под сайт «визитку» БУС, а клиенты платят, когда тот же бесплатный OctoberCMS позволяет собрать визитку на коленке почти не задумываясь об сложности, а клиенту выдать весьма удобный интерфейс управления, чем Инфоблоки битрикса (про типа Highload инфоблоки вообще молчу, отдельная маркетинговая ерунда)
Ох, заставили же Вы понастальгировать :)
Начинал разработку еще с php 3.5, помню хайп вокруг register_globals on и множества любителей и только зарождение ООП в php, веселое время было и замечательное, мы с пачкой энтузиастов начинали изучать php как один из простых языков. Было желание узнать все, официальная дока irc каналы, php-nuke как лучшая система и почти уникальная на тот момент…
По теме…
К сожалению в данный момент есть все то, чего не было у нас тогда. «Бестпрактикс», коммерция в сообществах, почти мертвый опенсоурс который так же стал коммерческим, абстракция на множество «чихов» и в основы уже почти ни кто не вдается, зачем основы если есть абстракция и документация по популярному yii, laravel, а множество пакетов позволяет собрать свою «цмс» просто настроив зависимости композера.
Было время, меня не взяли на работу из-за того, что не смог расшифровать по буквам аббревиатуру SOLID.
Я уже давно разрабатывал и соблюдал все эти принципы, но к сожалению с ходу не мог вспомнить расшифровку аббревиатуры которую читал и разбил больше нескольких лет назад.
Увы, из-за этого досадного ответа мне отказали в работе.
Насчет SET NAMES, это я помню еще по временам снова таки php 5, а именно это писалось и в документации к самому mysql расширению(http://php.net/manual/ru/function.mysql-set-charset.php), а так же по кодировке символов соединения (http://php.net/manual/ru/mysqlinfo.concepts.charset.php), ну и в догонку в самой документации по функции mysql_real_escape_string(http://php.net/manual/ru/function.mysql-real-escape-string.php) так же описано про использование встроенной функции установки кодировки. Плюс, суть работы функции mysql_set_charset является установкой клиентской кодировки(т.е. кодировки самой библиотеки клиента, плюс соединения с бд), в то время как SET NAMES устанавливает только session_set_client, character_set_connection и character_set_results, и помойму еще collation_connection в сортировку для указанной кодировки.
Так же если обратится к самой документации mysql, а именно к C API методу mysql_real_escape_string. Так же существуют предупреждения насчет SET NAMES — https://dev.mysql.com/doc/refman/5.5/en/mysql-real-escape-string.html
Я такой код только в 4 ветке видел, эх ностальгия.
Ну и по теме…
Забыли про XSS, CSRF, данный код от них ну никак не защищает/предохраняет/перекрывает/прекрывает и т д.
mysql_real_escape_string не панацея, а использование данной функции для фильтрации входящих целых чисел вообще добавляет уязвимость, в особенности если память не изменяет, то в кодировках SHIFT_JIS, BIG5, GB2312, EUC-JP, EUC-KR (мультибайтовых, utf8 не подвержен вроде как, хотя видел случаи с ним). Так же не стоит забывать, что функция mysql_real_escape_string не учитывает кодировку соединения(насколько помню на момент 2006 года), потому надо не забыть проставить mysql_set_charset()… Именно эта функция пакета mysql должна использоваться должна использоваться для выставления клиентской кодировки вместо запроса SET NAMES.
md5 давно уже не рекомендуется к использованию, если память не изменяет, то автоматизировали поиск коллизий по алгоритму md5 еще в 2006 году. Не зря от него отказались git в пользу sha1, так же sha1 широко используется не только в контроле версий но и в системах подписи… Да куда уж тут ходить, sha1 находится в основе SHACAL, что так же добавляет к нему доверие… За исключением гугла, они в него верить перестали :D
Насчет передачи айди. Все известные системы wp, bitrix, dle используют аналогичный подход(единственное он более совершенен в плане хранения) и где автор видел подход функции «запомнить» с передачей в куку только айди пользователя — не могу понять, вроде такая проблема была в php nuke, но уже столько воды утекло, что даже и представить не могу кто его еще использует О_о…
Так же во многих комментариях проскальзывало про mysql_* функции… С 2006 года весь пакет mysql находился в состоянии discouraged, потому что небыло человека который бы им занимался, а сообщество уже активно рекомендовало использовать mysqli расширение. Само расширение mysql вылетело в статус deprecated только с ветки php 5.5… Собственно не удивительно, ведь текущая разработка интерпретатора ведет и к постепенному выпиливанию mysqli расширения в пользу PDO.
P.S. Тем кто не верит в CSRF, она реальна и в последние годы набирает обороты в использовании. Не зря во всех популярных фреймворках идут встроенные методы защиты для передаваемых форм.
Честно говоря если бы не сообщили про 20 в разработке, возможно бы все сгладилось. Однако наблюдая код проекта, небрежность в структурировании и отсутсвие общепринятых стандартов - этот проект сложно будет привести в норму и 20 лет опыта к сожалению кажутся неправдой… не говоря о том, что поддержке php 7.4 остались считанные месяцы, а поддержка 8.0 должна истечь в следующем году.
Вашу разработку надо приводить к 8.1, начать декларировать и соответствовать общепринятому psr-12. А учитывая увиденное, это потребует не малых сил и вложений своего времени, к сожалению :(
А как быть при таком подходе в системах разделенных на модули? Когда есть отдельно модуль "пользователи" и отдельно модуль "новости", а тестирование по кейсу подразумевает первоначальное заполнение базы сидами. Особенно если у пользователей заранее есть роли, которые следует использовать, которые хранятся в БД и на роли так же созданы фабрики используемые в сидах?
Вторая версия октября стоит 9 долларов в год для проекта или 150 долларов для компаний/партнеров с неограниченным кол-вом лицензий, странно, что целая компания не может позволить себе это.
В этом и основная проблема, ошибки должны быть контролируемые. Фатальная ошибка от php это крайняя линия уже самого интерпретатора, а не приложения. То есть ошибок интерпретатора надо избегать, особенно если это данные которые приходят из запроса к серверу.
Зачем нужна фабрика, если есть возможность пользоваться конструктором объекта инициализируя только объект DTO, без необходимости задействовать левый объект ClassTransformer?
Ведь у нас нет необходимости создавать разные DTO в один и тот же момент, слой приложения в которое передаете DTO ждет конкретное DTO, соответсвенно лучше создавать его сразу, минуя лишний слой ClassTransformer'a.
Я понимаю если бы в ClassTransformer была дополнительная логика, например по маппингу, что в принципе не надо, но сложной логики по факту там нет.
> При такой реализации я не вижу особо профита использования, ведь я так же могу сам прописать new DTO() и заполнить параметры.
Суть DTO не только в заполнении, но и в том, что DTO должно передавать валидные данные между слоями. Инициализировать же объект с использованием конструктора передавая туда $request->valid() или через статичный метод transform промежуточного объекта трансформера — не играет особой разницы. В частых случаях, при работе с Request'ом во входящих параметрах контроллера, а контроллер должен быть последним слоем где используется Request объект — инициализацию DTO можно делегировать методу request'a объекта не забыв заранее создать интерфейс.
Пример:
Что позволит сделать контроллер более простым:
Я не особо вижу профита в промежуточном объекте вашего ClassTransformer'a для DTO который в целом при такой реализации выступает своего рода фабрикой DTO, при этом не обязательно, чтобы объект был DTO ведь скормить ему можно все что угодно, при этом отсутствует валидация типов.
Начал пользоваться OctoberCMS еще с беты, есть как сильные так и слабые стороны.
Один из весомых плюсов, весьма мощная и гибкая админка из коробки, что позволяет реализовывать банальные CRUD'ы и средние за весьма короткое время, для чего-то не стандартного так же все легко кастомизируется.
Конечно есть и минусы, в маркете не так много нужных плагинов, а на некоторые плагины весьма завышенная цена. Так же отсутствуют туториалы для редакторов и администраторов как в том же Bitrix или WP, но разок написав и передав клиенту, все в принципе решается.
Еще тем кто любит «чистоту» может не понравиться php код в административных шаблонах с форматом .htm.
EVO покрытие столешницы надеюсь съемное? иначе протрется мышкой и другими частями двигающимися по нему, нет желания менять его раз в год вместе со всей столешницей).
Какой сплав используется в раме, возможно есть ли возможность облегчить вес рамы или сделать более легкую модификацию, 10-17 кг все-таки многовато для крепления на стол, это еще без обвеса из мониторов, клавиатуры, пользователя.
Чем обусловлен выбор барашковых гайек для закрепления наклона столешницы? Они имеют свойство проскальзывать, врядли кто-то будет доставать ключ чтобы отрегулировать наклон каждый раз когда это необходимо, а затяжка с помощью рук «барашков», темболее металлических, не всегда эффективна (или мало каши ел, или болевой порог не позволяющий сильно затянуть рожки ибо пальцы болеть начинают), а при не эффективной затяжке, постоянно будут ослабевать стоит туда руки положить или со временем. Возможно стоит заменить на пластиковые фиксаторы с большей площадью с металлической гайкой в основании, чтобы можно было взять всей ладонью или хотябы обхватить (аналогично как в фиксаторы положения солнцезащитного козырька на дачных качелях :D), понадобится меньше усилия чтобы их расскрутить/закрутить.
Сам по себе БУС уже за свое время уже очень много вобрал легалиси, а об актуализации документации вообще молчу. Некоторые студии тянут под сайт «визитку» БУС, а клиенты платят, когда тот же бесплатный OctoberCMS позволяет собрать визитку на коленке почти не задумываясь об сложности, а клиенту выдать весьма удобный интерфейс управления, чем Инфоблоки битрикса (про типа Highload инфоблоки вообще молчу, отдельная маркетинговая ерунда)
Начинал разработку еще с php 3.5, помню хайп вокруг register_globals on и множества любителей и только зарождение ООП в php, веселое время было и замечательное, мы с пачкой энтузиастов начинали изучать php как один из простых языков. Было желание узнать все, официальная дока irc каналы, php-nuke как лучшая система и почти уникальная на тот момент…
По теме…
К сожалению в данный момент есть все то, чего не было у нас тогда. «Бестпрактикс», коммерция в сообществах, почти мертвый опенсоурс который так же стал коммерческим, абстракция на множество «чихов» и в основы уже почти ни кто не вдается, зачем основы если есть абстракция и документация по популярному yii, laravel, а множество пакетов позволяет собрать свою «цмс» просто настроив зависимости композера.
Я уже давно разрабатывал и соблюдал все эти принципы, но к сожалению с ходу не мог вспомнить расшифровку аббревиатуры которую читал и разбил больше нескольких лет назад.
Увы, из-за этого досадного ответа мне отказали в работе.
Так же если обратится к самой документации mysql, а именно к C API методу mysql_real_escape_string. Так же существуют предупреждения насчет SET NAMES — https://dev.mysql.com/doc/refman/5.5/en/mysql-real-escape-string.html
Вроде ничего не упустил.
Ну и по теме…
Забыли про XSS, CSRF, данный код от них ну никак не защищает/предохраняет/перекрывает/прекрывает и т д.
mysql_real_escape_string не панацея, а использование данной функции для фильтрации входящих целых чисел вообще добавляет уязвимость, в особенности если память не изменяет, то в кодировках SHIFT_JIS, BIG5, GB2312, EUC-JP, EUC-KR (мультибайтовых, utf8 не подвержен вроде как, хотя видел случаи с ним). Так же не стоит забывать, что функция mysql_real_escape_string не учитывает кодировку соединения(насколько помню на момент 2006 года), потому надо не забыть проставить mysql_set_charset()… Именно эта функция пакета mysql должна использоваться должна использоваться для выставления клиентской кодировки вместо запроса SET NAMES.
md5 давно уже не рекомендуется к использованию, если память не изменяет, то автоматизировали поиск коллизий по алгоритму md5 еще в 2006 году. Не зря от него отказались git в пользу sha1, так же sha1 широко используется не только в контроле версий но и в системах подписи… Да куда уж тут ходить, sha1 находится в основе SHACAL, что так же добавляет к нему доверие… За исключением гугла, они в него верить перестали :D
Насчет передачи айди. Все известные системы wp, bitrix, dle используют аналогичный подход(единственное он более совершенен в плане хранения) и где автор видел подход функции «запомнить» с передачей в куку только айди пользователя — не могу понять, вроде такая проблема была в php nuke, но уже столько воды утекло, что даже и представить не могу кто его еще использует О_о…
Так же во многих комментариях проскальзывало про mysql_* функции… С 2006 года весь пакет mysql находился в состоянии discouraged, потому что небыло человека который бы им занимался, а сообщество уже активно рекомендовало использовать mysqli расширение. Само расширение mysql вылетело в статус deprecated только с ветки php 5.5… Собственно не удивительно, ведь текущая разработка интерпретатора ведет и к постепенному выпиливанию mysqli расширения в пользу PDO.
P.S. Тем кто не верит в CSRF, она реальна и в последние годы набирает обороты в использовании. Не зря во всех популярных фреймворках идут встроенные методы защиты для передаваемых форм.