• Как правильно работать с объектами выборки doctrine в Symfony?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    дополню ответ Юрий

    Во первых, это на столько здоровый объект реляции images, что отдебажить его можно только с помощью функции dump.


    Все сущности заворачиваются в прокси объекты, что бы работала "магия" вроде ленивой подгрузки и т.д. Именно по этому в сущностях "больше" чем есть на самом деле.

    По поводу коллекций, в Doctrine есть такая штука как Collection. Вы должны понимать что в доктрине вы оперируете не табличками в базе, а объектами. Строите именно объектную модель вашей системы. В этом ключе можете почитать что такое "агрегат сущностей". В вашем случае у вас агрегат будет состоять из двух сущностей. Product и его Image. Например если вы захотите сделать добавление картинок, вы можете сделать так:

    /**
     * usage: $product->addImage($image);
     */
    public function addImage(Image $image)
    {
        $this->images->add($image);
    }


    А коллекция сама выполнит persist новой сущности. Таким образом количество репозиториев уменьшается до количества корней агрегатов сущностей. В вашем примере "корнем", то есть вершиной графа взаимоотношений объектов в контексте продуктов, является сам продукт. А потому репозиторий мы будем делать только для продуктов. Все остальное внутри оного разруливается либо при помощи коллекций.

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

    К примеру "новички" в доктрине любят персисть сущность даже для обновления. Они путают `persist` и `save`. Так вот, если вы загрузили сущность из базы через доктрину, то сущность уже попадает в unit of work. И делать persist уже не нужно, этот метод только для того чтобы доктрина узнала о чем-то новом. А так она и так знает про эту сущность. В итоге вы можете просто что-то поменять и вызвать flush. То есть репозиторий - это тупо хранилище. Хранилище умеет хранить. Изменять то, что оно хранит оно не может.

    Так же рекомендую на тему репозиториев почитать это:

    www.whitewashing.de/2013/03/04/doctrine_repositori...

    Ну и в целом.

    https://www.youtube.com/watch?v=rzGeNYC3oz0 - доклад о том как готовить доктрину от авторов оной.

    От себя лишь добавлю простые правила:

    - Не используйте напрямую доктриновские репозитории. Пишите свои, а в них уже юзайте доктриновские. Не стоит размазывать доктрину по всему проекту, потом это будет нереально поддерживать.
    - Не наследуйтесь от EntityRepository. Это внутренний механизм доктрины общего назначения. Используйте их в своих репозиториях со своим интерфейсом, повышая специфичность и ужесточая контроль за тем кто что юзает.
    - Старайтесь использовать entity manager только в своих репозиториях и каких то небольших сервисах. Не размазывайте все по всюду.

    что очень сильно срет память.


    Доктрина гарантирует вам что в памяти будет всегда только один инстанс сущности. То есть если у вас есть 10 объектов одного типа и имеющих один объект, это все будут ссылки на одну сущность. В вашем случае у вас просто циклическая ссылка между продуктами и изображениями. dump циклические ссылки не особо умеет.

    Это логичное ограничение, дабы не возникало ситуаций что вы обновили что-то в одном экземпляре сущности и что-то в другом, и в базу попадут только часть изменений. За подробностями - читайте документацию к доктрине в отношении UnitOrWork и Identity Map.
    Ответ написан
  • В каком месте mvc системы должен находиться шаблонизатор?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1. шаблонизатор - это просто компонент. Они ничего не знает о MVC и прочем булшите
    2. шаблонизатор нужен там, где формируется view. Вы можете крутиться как хотите, но view на бэкэнде пассивно (это http ответ) в подавляющем большинстве реализаций (даже в ADR от которого нынче писают кипятком), а это значит что формироваться view будет в контроллере. Отсюда делаем вывод что шаблонизатор должен дергаться в контроллере а такого компонента как view у нас просто нет. Возможны хэлперы которые помогают формировать этот самый view но не более.
    3. управление зависимостями не входит в зону ответственности MVC. Оно обычно где-то сверху, тут можно заюзать Dependency Injection (только готовый контейнер если, свой не пишите).
    4. трейты в контроллерах нормальная тема просто потому что на код контроллеров нам должно быть плевать с высокой колокольни. Если вам не плевать на код контроллеров - возможно вы там делаете что-то чего контроллеры делать не должны. Ну и опять же это будет трейт который будет делегировать задачу шаблонизатору а не реализовывать его.
    5. что-то мне подсказывает что "модель" в вашей системе координат это какой-нибудь класс для работы с базой данных. Если так - вы не поняли зачем вообще вводится это разделение.
    Ответ написан
    Комментировать
  • Какую литературу посоветуете по PHP?

    nepster-web
    @nepster-web
    "Слышал только отрицательные отзывы" - это от дурачков, которые не следят за развитием.

    "Вроде как, в PHP ввели ООП" - да было такое, лет 6 назад (имеется ввиду нормальное ООП).

    Мэтт Зандстра - PHP: объекты, шаблоны и методики программирования. 4-е издание.

    На сегодняшний день PHP развивается быстрее всех и обладает почти всеми кртыми финчами, которые нужна для разработки больших проектов (менеджер пакетов, трейты, лямбда выражения, замыкания, нэймспейсы, рефлекшин, да да привет аннотации и многое другое). Уже можно разрабатывать десктопные приложения и есть расширения для работы api операционных систем. Не давно был релиз php7, который добавил некоторые возможности для работы с типизацией и существенно оптимизировал ядро.

    Да вроде есть проблемы еще с потоками и демонами на php, но я думаю это порешают, не смотря на то, что он вообще не для этого создавался.

    И помните, один язык программирования любой это говно, по сравнению со стеком, где используется множество технологий под каждую задачу. Например нельзя сравнивать php vs js vs go, эти языки решают совершенно разные задачи.
    Ответ написан
    5 комментариев
  • Подскажи лучшую книгу по php самую обеьмную по информации с Учетом ООП и общих тем ??

    ppokrovsky
    @ppokrovsky
    www.apress.com/9781430260318

    PHP Objects, Patterns, and Practice
    4th Edition
    By Matt Zandstra

    Он использует странный синтаксис местами, но я считаю это одной из лучших книг по ООП в PHP потому что там проведены параллели с GoF.
    Ответ написан
    Комментировать
  • Как научиться писать такой ООП код?

    SilenceOfWinter
    @SilenceOfWinter Куратор тега PHP
    та еще зажигалка...
    Мэтт Зандстра - PHP. Объекты, шаблоны и методики программирования
    Ответ написан
    2 комментария
  • Как получить результат выполнения js скриптов на странице?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    phantom.js, если на стороне сервера вам это нужно сделать. Или какой другой headless-браузер.
    Ответ написан
    4 комментария
  • Реализация MVC Yii (связи моделей, каскадное удаление)?

    @CoolerMan Автор вопроса
    Короче как я понял у нас есть для работы с одной таблицей:
    delete All
    update All
    Save
    Insert
    Find all

    Возможна жадная загрузка из relations
    With

    Остальные методы
    Массового insert, delete, update мы используем CDbCriteria
    Ответ написан
    Комментировать
  • Возможно ли получить статус юзера(онлайн/офлайн) на XMPP-сервере, если его нет в контакт-листе?

    Предположу, что используя клиент вы можете попытаться искать пользователя и попытаться отобразить его статус\информацию о нем.
    Не получиться, если у вас нет доступа к серверной части, если вы это имеете в виду.
    Ответ написан
    Комментировать
  • Возможно ли получить статус юзера(онлайн/офлайн) на XMPP-сервере, если его нет в контакт-листе?

    Anonym
    @Anonym
    Программирую немного )
    Нет. Вы должны быть подписаны на этого пользователя, чтобы получить его статус.
    Ответ написан
    Комментировать