Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Посмотрел исходники. Тесты? SOLID? Вобщем как минимум рефакторить вам надо сие творение.
Плюсану однако, делиться кодом это хорошо.
Плюсану однако, делиться кодом это хорошо.
Спасибо, я с удовольствием приму любую критику по делу, вы мне как минимум полезные мысли уже подсказали (конкретно разобраться в SOLID-принципах, поиграться с автотестами). Если не делиться своими наработками — полезную критику получить гораздо сложнее. Плюс, имхо, даже в таком виде модуль уже может приносить пользу не только мне.
Тоже плюсанул за старания, но не вижу смысла в этой штуке учитывая это:
Смысл Highload iblocks как раз в том, что бы обойти тормозное iblock-api. А вы просто сделали (не доделали) новое АПИ. В чём смысл?
Работает с уже существующим API для работы с данными инфоблоков, а не напрямую с базой.
Смысл Highload iblocks как раз в том, что бы обойти тормозное iblock-api. А вы просто сделали (не доделали) новое АПИ. В чём смысл?
Смысл в
0) именно новом API :)
1) удобстве работы, написании новых компонентов например
2) можно заюзать ORM, понравится код писать в таком ключе — уже тогда переписать ту часть, что отвечает за работу с базой.
3) ORM не сломается, если в очередном патче поменяется внутренняя логика работы с базой
4) Highload iblocks, судя по доступной информации, будет работать «с отдельным NoSQL хранилищем». Т.е., это будет отдельная структура, параллельная инфоблокам. Для существующих сайтов без существенной переделки профита не достичь.
0) именно новом API :)
1) удобстве работы, написании новых компонентов например
2) можно заюзать ORM, понравится код писать в таком ключе — уже тогда переписать ту часть, что отвечает за работу с базой.
3) ORM не сломается, если в очередном патче поменяется внутренняя логика работы с базой
4) Highload iblocks, судя по доступной информации, будет работать «с отдельным NoSQL хранилищем». Т.е., это будет отдельная структура, параллельная инфоблокам. Для существующих сайтов без существенной переделки профита не достичь.
Мы тоже написали свою ORM для битрикса, но немного в не в таком ключе как у вас. Наши сущностные классы не привязаны напрямую к api битрикса, а работа с api идет через мепперы.
Таким образом, мы легко можем и юнит тесты писать, да и вообще делать много интересных штук (например, дублирование и синхронизацию данных ИБ в mongodb, и поиск на фронте делать по монге, что дает существенные бонусы, а если еще взять и работу с геоданными, то восторг программистов не описать словами :) )
Из минусов — естественный оверхед в dto и т.п. Но на больших проектах преимущества побеждают геморрои :)
Таким образом, мы легко можем и юнит тесты писать, да и вообще делать много интересных штук (например, дублирование и синхронизацию данных ИБ в mongodb, и поиск на фронте делать по монге, что дает существенные бонусы, а если еще взять и работу с геоданными, то восторг программистов не описать словами :) )
Из минусов — естественный оверхед в dto и т.п. Но на больших проектах преимущества побеждают геморрои :)
Эх, любопытно было бы в коде вашем покопаться… :)
К сожалению выложить в паблик не могу.
Вообще, архитектурно ничего сверхъестественного нету, решения вполне стандартные и описанные в любом источнике по DDD.
Изначально у нас был вариант а-ля Active Records, был базовый класс сущности, который мог сохранять элемент в ИБ, от этого класса наследовались другие сущностные классы. Все свойства у классов были описаны в phpdoc нотациях, поэтому в модулях и компонентах оперировали только объектами, с нормальной поддержкой от IDE.
Но при росте сложности AR модель начинает показывать свои недостатки, вот, и поэтому переписали работу с ИБ.
Мепперы — это прослойка, которая берет сущностные классы или контексты данных и сохраняет в БД. В этом случае получается бизнес уровень полностью независимый от субд и прочего. Это дает довольно хорошие бонусы, по сути, мы можем нашу логику перенести под что угодно, например, переписать все под symfony (ну а мы, например, сделали свои high load iblock, не дождались так сказать :)). Ну, а недостаток, как я уже написал — это увеличение по сути бесполезного кода в мепперах.
Вопрос, тут на самом деле в другом, на какой черт надо городить все это в битре, потому что для сайта визитки или типового магазина данный функционал будет больше вредить. А на проектах, где реально начинают проявляться бонусы DDD, использовать битру как минимум сомнительно.
Вообще, архитектурно ничего сверхъестественного нету, решения вполне стандартные и описанные в любом источнике по DDD.
Изначально у нас был вариант а-ля Active Records, был базовый класс сущности, который мог сохранять элемент в ИБ, от этого класса наследовались другие сущностные классы. Все свойства у классов были описаны в phpdoc нотациях, поэтому в модулях и компонентах оперировали только объектами, с нормальной поддержкой от IDE.
Но при росте сложности AR модель начинает показывать свои недостатки, вот, и поэтому переписали работу с ИБ.
Мепперы — это прослойка, которая берет сущностные классы или контексты данных и сохраняет в БД. В этом случае получается бизнес уровень полностью независимый от субд и прочего. Это дает довольно хорошие бонусы, по сути, мы можем нашу логику перенести под что угодно, например, переписать все под symfony (ну а мы, например, сделали свои high load iblock, не дождались так сказать :)). Ну, а недостаток, как я уже написал — это увеличение по сути бесполезного кода в мепперах.
Вопрос, тут на самом деле в другом, на какой черт надо городить все это в битре, потому что для сайта визитки или типового магазина данный функционал будет больше вредить. А на проектах, где реально начинают проявляться бонусы DDD, использовать битру как минимум сомнительно.
primepix Насчет кода понимаю, но в данный момент я пытаюсь понять общую вашу концепцию, методику встраивания. Как вы интегрировались с битриксовской админкой? Вы целиком отказались от обычных инфоблоков? Или дублировали инфоблочную структуру в отдельных таблицах? Извините за назойливость, но уж больно понять идею хочется. :)
Нет, совсем от ИБ мы не отказывались. В нашем случае ИБ это как бы база данных. Поэтому все родное (админка и другие модули) работают нормально, без изменений.
ИБ структуру так же нигде для этих целей не дублировали (кроме как в монго для кеширования и поиска). Поиск по API битры возвращает только ID'шники, а потом по ним из монго тянется весь объект. Где удобнее — ищем в монге. Тут суть в том, что битрикс делает доп. запросы, чтоб собраться все свойства элемента и сами запросы могут быть сложные за счет пачки join'ов. В монго же хранится «плоская» структура, т.е. объект сразу со всеми свойствами.
Когда администраторы системы меняют что-то в админке, то после сохранения срабатывает битровый хук и данные обновляются в монго.
ИБ структуру так же нигде для этих целей не дублировали (кроме как в монго для кеширования и поиска). Поиск по API битры возвращает только ID'шники, а потом по ним из монго тянется весь объект. Где удобнее — ищем в монге. Тут суть в том, что битрикс делает доп. запросы, чтоб собраться все свойства элемента и сами запросы могут быть сложные за счет пачки join'ов. В монго же хранится «плоская» структура, т.е. объект сразу со всеми свойствами.
Когда администраторы системы меняют что-то в админке, то после сохранения срабатывает битровый хук и данные обновляются в монго.
Что еще заявлено, но не существует в битриксе?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Самопальная ORM для Битрикс