Все стараются бороться с глобальными сущностями. Laravel: на тебе фасад, на тебе сигнлтон, на тебе глобальный объект :D
Ну а если по теме: чем этот подход лучше, обычного прокидывания сервиса через DI? Инджектим NotificationService в контроллере, инджектим в месте использования - профит. DI контейнер уже заботиться о том, чтобы инстанс был единственным экземпляром. Для такого способа как минимум будет меньше кода чем сейчас и нельзя будет вызывать NotificationService в любой точке кода (на всякий случай уточню что это херня полнейшая вызывать глобальные объекты где попало ;-) ).
Ну и по логики генерации заголовка: почему логика в NotificationResource? Это должно быть либо в фабрике DTO, либо внутри самого DTO (но это вариант опустим, т.к. в этом случае DTO перестанет быть DTO). А так получается что логика относящаяся к DTO утекла куда-то в другое место, которое никакое отношение не имеет к самому объекту.
Импакт от этого - переполнение базы данных путем создания различных юзеров.
А каким образом? Код одноразовый, т.е. когда мы его использовали, больше уже не получиться его использовать повторно.
После использования, если sid опять будет сгенерирован, то код проверки для него будет уже другой. И по факту написанный выше скрипт сработает только 1 раз.
Кажется тестировщики все же должны использовать реальные ящики ;)
Плюс визуал эта тулза точно корректно передает? В почте не просто HTML, там много своих ньюансов, и по хорошему надо смотреть популярные почтовые клиенты: Outlook, Gmail, Thunderbird и т.д.
Ну а если просто надо содержимое, то файлика в логе будет достаточно.
Это я к тому, что в зависимости от задачи тащить целый MailCatcher, может быть оверхедом. А в статье он как панацея обозначается)
Далее заходим в поисковик Яндекса и набираем ключевые слова: "английского репа MF DOOM
Просто случайно не заметили запятую в списке ключевых слов, да-да. Конечно же это человеческий запрос, все же мы гуглим именно так, а не по имени исполнителя. Нет-нет, конечно это все не ради красивой картинки с выдачей ТОП-1
Даже не знаю что хуже: что из пальца высасывают, либо что seo-шникой настолько тупой.
Да уже забудьте про эту хрень и не заучивайте её. SOLID проще и для понимания и для использования.
8 Какая система типов используется в PHP? Опишите плюсы и минусы.
Это вопрос из 90-х? Строгая типизация куда пропала?
19 Будут ли доступны частные методы trait в классе?
Ответ "Можно" :D
21 Расскажите об обработке ошибок и исключения (try catch, finaly и throw). Исключения необходимо для информативного оповещения об ошибке приложения.
Точно для этого? Я могу и 'trigger_error' заиспользовать, чтобы информативно что-то сообщить.
22 Что такое type hinting, как работает, зачем нужен?
После указанного ответа сразу же возникает вопрос "и что это дает?"
23 Что такое namespace-ы и зачем они нужны?
Удобное структурирование и группировка кода по контекстам (или иным причинам) вышли из чата.
29 Что такое замыкание в PHP? Приведите пример.
После указанного ответа сразу же возникает вопрос "зачем это use используется?"
31 Что такое позднее статическое связывание? Расскажите о поведении и применения static.
Ответ не понятнее вопроса :D
34 Расскажите о принципах SOLID. "Принцип единственной ответственности - Каждый объект ... а все его сервисы должны быть ..."
Это что за такие сервисы класса? У класс/объекта только свойства и методы.
34 Расскажите о принципах SOLID. "Это означает, что эти сущности могут менять свое поведение без изменения их исходного кода."
Это как? Я же должен написать код, чтобы что-то поменять в наследнике? Может тут все-таки речь про расширение поведения, с невозможность изменить изначальное?
34 Расскажите о принципах SOLID. "Принцип разделения интерфейса"
Это все хорошо (на самом деле нет), а интерфейсы то тут при чем? Если какой-то метод не используется клиентом, то этого метода не должно быть в интерфейсе!
-
Если честно я уже думал на этом закончить чтиво, но после увидел это:
И этот действительно богатый набор встроенного API по сути и выделяет его из массы других движков на сегодня и даёт вход в категорию CMF (content management framework), вроде как среднее звено между традиционным сайтовым движком и полноценным php web-фреймворком.
У WP или Joomla по вашему API меньше? Ссылку бы хотя бы на API оставили, чтобы понимать масштаб :) Забавно что вы мерите категорию фреймворк/не фреймворк размером API. Slim и емуподобные конечно грустят в сторонке от такого неравенства.
...стабильность движка с продуманной кодовой основой.
Что вкладывается в слово "стабильность"? Наличие мажорной цифры в номере версии? Малое число issue, а также отсутствие тестов (по крайней мере в репе) говорит скорее об обратном и том что могут быть скрытые дефекты.
Стабильно плохо - это все равно плохо :)
Касательно уникальности & гибкости дизайна - тут опять свобода (а это часто предполагает ответственность), задействуй css библиотечки на вкус и на тебе авторский сайт(!)
А у кого нет?
какие поля не создавай в админке, сообразно таблицы и типы формируются в базе, и далее манипулируются через ту же админ-панель.
А у кого нет?
Безопасность, производительность, ... - это всё про PW.
Плюс в комментариях выше правильно написали про использованную память. Я думаю стоит также добавить в статью сколько памяти сожралось при том или ином варианте.
Ну и еще как вариант можно запросы делать пачками по 1К, 10К, 100К элементов, а не собирать один большой монструозный запрос
В данном случае сущности 1 к 1 отражают таблицу и то как хранятся в базе сущности. Дополнительно к этому они нагружены еще и бизнес-логикой. У вас не получиться в эти объекты добавить логику и данные, которые будут идти в разрез с БД - доктрина подавится.
То что что в данных объектах нет метода save и delete, т.е. они не инкапсулируют в себе работу с базой, это еще не значит что они не AR (возможно не совсем в классическом понимании).
Партиции хранятся в одной БД, шардирование это разнос данных по разным БД. Условие разделение уже задаете какое вам нравится в обоих случаях (в случае с шардированием можете часть таблиц целиком вынести на другой сервер).
Ну то есть вы не разобрались как работает метод тестирования, какие есть у него варианты, не стали гуглить или хотя бы читать описание к самим методам, а просто решили написать статью о своей глупости?
Альтернатива: сниппет в IDE и не нужен никакой сомнительный велосипед
С несколько меньшей дальше пойдёт изучать язык. Станет отличным бекендером битрикса, ибо знает поверхность админки уже как свои пять пальцев
Опять же:
Только вопрос: как мне это развидеть? Что помешало сделать таблицы для компонентов, и для конфигов (а это конфиг реально), и вместо вороха строк передавать ID записи в базу?
1 компонент может иметь несколько шаблонов, и кучу мест использования (все это по вашей теории нужно хранить в базе). С таким же успехом предлагайте в Yii2 виджеты хранить в базе.
Плюс в таком варианте кеширование компонента будет работать все равно с базой, вместо того чтобы просто сразу все выплюнуть из кеша.
Ну и собственно такая простыня параметров нужна для того чтобы компоненты были как можно более универсально (чтобы люди могли спокойной в виз редакторе натыкать нужные параметры и не заглядывать в код или кастомизировать шаблон/компонент).
Ну и, опять же, в моём учебном проекте было ещё до меня... 744 таблицы
Это вы еще Битрикс24 не смотрели, где 1.3К таблиц. Правда если спросить "а в чем проблема?" вы вряд ли сможете дать ответ.
Веселят конечно люди, которые засирают Битрикс поработав на нем 1-2 дня/недели, и потом говорят насколько в нем все плохо. Ах да и пишут на старом коде версии этак 15-ой. С таким же успехом можно говнить Yii2 приводя примеры из Yii1. Если не нравится писать на файлах - пишите контроллеры к роутеру который есть в Битрикс (неожиданно правда, а он оказывается есть);
Судя по вашему описанию "есть карточка с артикулами, а остальное хранится в базе" вы вообще понятия не имеете как устроена архитектура: есть страница (на ней подключается пролог и эпилог), на этой странице указываются компоненты (хоть руками, хоть из виз. редактора), внутри компонента уже есть логика и шаблоны.
Если вы смотрите на задачу с точки зрения верстальщика, то вам нужны только шаблоны - обычные php файлы с версткой, которым компонент скормил данные для отображения (удивительно, но это ой как похоже на View из MVC, но в других фреймворках у вас это вопросы не вызывало, а тут почему-то вызывало).
Да и подключение файлов style.css и script.js к шаблону компонента происходит автоматически, и не обязательно дергать Assets для ручного подключения.
Прежде чем выплескивать кашу из своей головы, я думаю стоит почитать документацию как работать с Битрикс, а не какие-то рандомные статьи из интернета.
Опять же, двойные стандарты: почитать доку к какому то фреймворку - ок, так и нужно делать. А вот для Битрикса - нахер надо, по наитию не пойму - Битрикс говно. Логика - великолепная :)
Если нормально писать модули и компоненты то никакой проблемы нет (уже лет 5 наверное).
Все что внутри директории модуля /lib автоматически загружается (даже оказывается согласно PSR-4, но автору об этом знать не обязательно, пусть дальше живет в своих розовых фантазиях о ларавеле :)
Все стараются бороться с глобальными сущностями. Laravel: на тебе фасад, на тебе сигнлтон, на тебе глобальный объект :D
Ну а если по теме: чем этот подход лучше, обычного прокидывания сервиса через DI? Инджектим NotificationService в контроллере, инджектим в месте использования - профит. DI контейнер уже заботиться о том, чтобы инстанс был единственным экземпляром. Для такого способа как минимум будет меньше кода чем сейчас и нельзя будет вызывать NotificationService в любой точке кода (на всякий случай уточню что это херня полнейшая вызывать глобальные объекты где попало ;-) ).
Ну и по логики генерации заголовка: почему логика в NotificationResource? Это должно быть либо в фабрике DTO, либо внутри самого DTO (но это вариант опустим, т.к. в этом случае DTO перестанет быть DTO). А так получается что логика относящаяся к DTO утекла куда-то в другое место, которое никакое отношение не имеет к самому объекту.
А каким образом? Код одноразовый, т.е. когда мы его использовали, больше уже не получиться его использовать повторно.
После использования, если sid опять будет сгенерирован, то код проверки для него будет уже другой. И по факту написанный выше скрипт сработает только 1 раз.
Что я упускаю?
Кажется тестировщики все же должны использовать реальные ящики ;)
Плюс визуал эта тулза точно корректно передает? В почте не просто HTML, там много своих ньюансов, и по хорошему надо смотреть популярные почтовые клиенты: Outlook, Gmail, Thunderbird и т.д.
Ну а если просто надо содержимое, то файлика в логе будет достаточно.
Это я к тому, что в зависимости от задачи тащить целый MailCatcher, может быть оверхедом. А в статье он как панацея обозначается)
Решение реализовать свой
custom_mailи писать почту в лог файлик, почему не подошло?https://dev.1c-bitrix.ru/community/webdev/user/16002/blog/1073/
Просто случайно не заметили запятую в списке ключевых слов, да-да. Конечно же это человеческий запрос, все же мы гуглим именно так, а не по имени исполнителя. Нет-нет, конечно это все не ради красивой картинки с выдачей ТОП-1
Даже не знаю что хуже: что из пальца высасывают, либо что seo-шникой настолько тупой.
А когда это массив и объект скалярами стали? https://www.php.net/manual/ru/function.is-scalar
Да уже забудьте про эту хрень и не заучивайте её.
SOLID проще и для понимания и для использования.
Это вопрос из 90-х? Строгая типизация куда пропала?
Ответ "Можно" :D
Точно для этого? Я могу и 'trigger_error' заиспользовать, чтобы информативно что-то сообщить.
После указанного ответа сразу же возникает вопрос "и что это дает?"
Удобное структурирование и группировка кода по контекстам (или иным причинам) вышли из чата.
После указанного ответа сразу же возникает вопрос "зачем это
useиспользуется?"Ответ не понятнее вопроса :D
Это что за такие сервисы класса? У класс/объекта только свойства и методы.
Это как? Я же должен написать код, чтобы что-то поменять в наследнике?
Может тут все-таки речь про расширение поведения, с невозможность изменить изначальное?
Это все хорошо (на самом деле нет), а интерфейсы то тут при чем?
Если какой-то метод не используется клиентом, то этого метода не должно быть в интерфейсе!
-
Если честно я уже думал на этом закончить чтиво, но после увидел это:
ЗАЧЕМ? Зачем про это спрашивать?
У WP или Joomla по вашему API меньше? Ссылку бы хотя бы на API оставили, чтобы понимать масштаб :)
Забавно что вы мерите категорию фреймворк/не фреймворк размером API. Slim и емуподобные конечно грустят в сторонке от такого неравенства.
Что вкладывается в слово "стабильность"? Наличие мажорной цифры в номере версии? Малое число issue, а также отсутствие тестов (по крайней мере в репе) говорит скорее об обратном и том что могут быть скрытые дефекты.
Стабильно плохо - это все равно плохо :)
А у кого нет?
А у кого нет?
Пруфы?
Статья про транзакции, а не про вложенность. Вложенность работает так под капотом:
Статья хорошая, но в целом про работу с сохранением из коллекции в доке есть: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=11749&LESSON_PATH=3913.3516.5748.11743.11749
Плюс в комментариях выше правильно написали про использованную память. Я думаю стоит также добавить в статью сколько памяти сожралось при том или ином варианте.
Ну и еще как вариант можно запросы делать пачками по 1К, 10К, 100К элементов, а не собирать один большой монструозный запрос
Т.е. в сервис локаторе у вас лежит элемент с именем EXAMPLE, который подразумевает обработку команды и это по вашему ок?
Далее в системе появляется обработчик комманд от другого микросервиса, с таким же названием. Что делать в данном случае?
Не лучше завести отдельный диспетчер для задач и сконектить его с ларавельной логикой?
Ну собственно описанные сущности это и есть AR. Определение Мартина: https://martinfowler.com/eaaCatalog/activeRecord.html
В данном случае сущности 1 к 1 отражают таблицу и то как хранятся в базе сущности. Дополнительно к этому они нагружены еще и бизнес-логикой. У вас не получиться в эти объекты добавить логику и данные, которые будут идти в разрез с БД - доктрина подавится.
То что что в данных объектах нет метода save и delete, т.е. они не инкапсулируют в себе работу с базой, это еще не значит что они не AR (возможно не совсем в классическом понимании).
Точно?
Давайте разбираться: у нас есть объект который объединяет в себе логику и структуру БД (в данной статье
App\Entity\Car|Buggy|Auto).Где здесь маппер? :)
А можно ведь было сделать отдельные классы на сущности домена, мапить их при сохранении в таблицу и не насиловать бедные ActiveRecord'ы из доктрины :)
Если верить вики, то вы не весь список управляющих конструкций описали :) https://ru.wikipedia.org/wiki/BPMN
Плюс можно было бы написать какой софт использовать для их построения. Инструмента автоматизации которые работают на базе таких схем.
Короче тема не раскрыта :(
Партиции хранятся в одной БД, шардирование это разнос данных по разным БД. Условие разделение уже задаете какое вам нравится в обоих случаях (в случае с шардированием можете часть таблиц целиком вынести на другой сервер).
"Две пыхи" - РНР это язык. Либо вы имели ввиду что-то другое, либо с подачей информации ооооооооочень большие проблемы.
Ну то есть вы не разобрались как работает метод тестирования, какие есть у него варианты, не стали гуглить или хотя бы читать описание к самим методам, а просто решили написать статью о своей глупости?
Великолепие как оно есть :)
Исходный код и визуальный редактор это два вида языка? Чтооооооо?
Нифига себе, вы изобрели включаемые области которые есть в Битрикс с самого начала: https://dev.1c-bitrix.ru/api_help/main/reference/cmain/includefile.php
Альтернатива: сниппет в IDE и не нужен никакой сомнительный велосипед
Опять же:
1 компонент может иметь несколько шаблонов, и кучу мест использования (все это по вашей теории нужно хранить в базе). С таким же успехом предлагайте в Yii2 виджеты хранить в базе.
Плюс в таком варианте кеширование компонента будет работать все равно с базой, вместо того чтобы просто сразу все выплюнуть из кеша.
Ну и собственно такая простыня параметров нужна для того чтобы компоненты были как можно более универсально (чтобы люди могли спокойной в виз редакторе натыкать нужные параметры и не заглядывать в код или кастомизировать шаблон/компонент).
Это вы еще Битрикс24 не смотрели, где 1.3К таблиц. Правда если спросить "а в чем проблема?" вы вряд ли сможете дать ответ.
Веселят конечно люди, которые засирают Битрикс поработав на нем 1-2 дня/недели, и потом говорят насколько в нем все плохо.
Ах да и пишут на старом коде версии этак 15-ой. С таким же успехом можно говнить Yii2 приводя примеры из Yii1. Если не нравится писать на файлах - пишите контроллеры к роутеру который есть в Битрикс (неожиданно правда, а он оказывается есть);
Судя по вашему описанию "есть карточка с артикулами, а остальное хранится в базе" вы вообще понятия не имеете как устроена архитектура: есть страница (на ней подключается пролог и эпилог), на этой странице указываются компоненты (хоть руками, хоть из виз. редактора), внутри компонента уже есть логика и шаблоны.
Если вы смотрите на задачу с точки зрения верстальщика, то вам нужны только шаблоны - обычные php файлы с версткой, которым компонент скормил данные для отображения (удивительно, но это ой как похоже на View из MVC, но в других фреймворках у вас это вопросы не вызывало, а тут почему-то вызывало).
Да и подключение файлов style.css и script.js к шаблону компонента происходит автоматически, и не обязательно дергать Assets для ручного подключения.
Прежде чем выплескивать кашу из своей головы, я думаю стоит почитать документацию как работать с Битрикс, а не какие-то рандомные статьи из интернета.
Опять же, двойные стандарты: почитать доку к какому то фреймворку - ок, так и нужно делать. А вот для Битрикса - нахер надо, по наитию не пойму - Битрикс говно.
Логика - великолепная :)
Вам наверное неизвестно что такое "обратная совместимость"
Если нормально писать модули и компоненты то никакой проблемы нет (уже лет 5 наверное).
Все что внутри директории модуля
/libавтоматически загружается (даже оказывается согласноPSR-4, но автору об этом знать не обязательно, пусть дальше живет в своих розовых фантазиях о ларавеле :)