В чём техническое превосходство Magento перед Битрикс, OpenCart, PrestaShop и другими системами управления интернет-магазинами?

[16 июля 2019 г.]    Российская сборка Magento 2.52.2
Magento 2: модули и услуги
magereport.com: составление перечня необходимых для установки заплаток SUPEE
#1 Дмитрий Федюк
  • Администратор
  • Иконка
  • Группа: Администратор
  • Сообщений: 8995
  • Регистрация: 20.02.2010

22.03.2010 14:19

Ключевой задачей внедрения системы управления интернет-магазином является адаптация этой системы к потребностям конкретного заказчика.

Системы управления бывают двух типов:
  • самописные
  • тиражируемые


Самописные системы, как правило:
  • дороги на этапе сопровождения (потому что никто кроме создателя системы не знает, как она работает, и помимо платы непосредственно за работу Вам придётся платить подрядчику и за обучение, причём полученные на Вашем проекте знания и навыки работы с Вашей самописной системой этот подрядчик больше нигде не сможет применить).
  • быстро устаревают (потому что система разрабатывается единократно под Ваш конкретный магазин и больше её никто, кроме Вас, развивать не будет)
  • плохо масштабируются (потому что Вы платили подрядчику за Ваши сегоднящние требования, и за будущие нагрузки системы ему никто не платил).


Тиражируемые системы, как правило, лучше по всем вышеперечисленным пунктам.
В чём же отличие Magento от других тиражируемых систем: Битрикс, OpenCart, PrestaShop и других?

Итак, есть тиражируемый движок. Есть потребности конкретного заказчика. Или, возможно, в самом движке присутствует дефект. Внимание, вопрос: что делать?
Напрямую вносить изменения в файлы движка плохо по очевидным причинам:
  • заказчик теряет возможность обновления версий движка. Движок развивается - заказчик стоит на месте, и его сайт устаревает.
  • поведение движка становится всё менее стандартным, и движок всё более превращается в самописный. Самописный движдок дороже в сопровождении (программистам надо вникать в него), менее стабилен в работе (самописный код тестируется ровно на одном самописном сайте, а не всей клиентской базой тиражируемого движка)


Что же делать?

Хороший тиражируемый движок в той или иной степени поддерживает модульность своей архитектуры: можно менять функциональность движка, добавляя к нему модули (плагины, компоненты, расширения, темы, шаблоны - терминология зависит от конкретного движка).

Но я не встречал ни одного движка, кроме Magento, который позволял бы точечно менять поведение системных объектов ядра движка из стороннего модуля.
Происходит это классическим объектно-ориентированным способом: наследуетесь от системного класса, перекрываете требуемый метод системного класса и свой класс-наследник помещаете в свой модуль, который затем подключаете к Magento.

(Всё это волшебство становится возможным благодаря применению отличных паттернов проектирования при разработке архитектуры Magento. В частности, все объекты (и системные, и подключаемых модулей) создаются с применением паттерна Factory. Это делает возможным переопредетить тип создаваемого объекта: например, с системного класса-родителя на класс-потомок стороненнего модуля.)

Преимущества такого подхода гигантские:
  • Все правки ядра сосредоточены в одном месте - стороннем модуле, код которого чётко отделён от кода движка.
  • Этот модуль можно подключать и отключать в любой момент.


Приведу пример. Внёс программист изменения в программный код интернет-магазина. Вроде всё работает. Потом вдруг обнаруживается критический дефект. Что делать? В другом движке пришлось бы откатывать внесенные изменения, взяв предыдущую версию кода из системы контроля версий. Этот процесс достаточно трудоёмок (может занять несколько часов работы программиста).

В Magento же достаточно зайти в админку и отключить конфликтный модуль.

В следующей статье, сугубо технической, для программистов, я расскажу, как посредством своих модулей вносить изменение в поведение движка Magento.

#2 core
  • Группа: Пользователь
  • Сообщений: 6
  • Регистрация: 08.08.2011

08.08.2011 01:58

Следует учитывать, что в админке имеется возможность отключить лишь блоки, отрисовываемые модулем, на фронте, т.к. проверка опции происходит лишь при рендере блоков. Логика модуля при этом будет по прежнему включена в работу системы (контроллеры, обсерверы и т.д.). Полностью отключить модуль возможно лишь на уровне xml конфига. Так что эта опция не дублирует данную возможность, а предоставляет несколько другой уровень управления поведением системы.

Поделиться темой: