Вход
Регистрация
Помощь
Системы управления бывают двух типов:
- самописные
- тиражируемые
Самописные системы, как правило:
- дороги на этапе сопровождения (потому что никто кроме создателя системы не знает, как она работает, и помимо платы непосредственно за работу Вам придётся платить подрядчику и за обучение, причём полученные на Вашем проекте знания и навыки работы с Вашей самописной системой этот подрядчик больше нигде не сможет применить).
- быстро устаревают (потому что система разрабатывается единократно под Ваш конкретный магазин и больше её никто, кроме Вас, развивать не будет)
- плохо масштабируются (потому что Вы платили подрядчику за Ваши сегоднящние требования, и за будущие нагрузки системы ему никто не платил).
Тиражируемые системы, как правило, лучше по всем вышеперечисленным пунктам.
В чём же отличие Magento от других тиражируемых систем: Битрикс, OpenCart, PrestaShop и других?
Итак, есть тиражируемый движок. Есть потребности конкретного заказчика. Или, возможно, в самом движке присутствует дефект. Внимание, вопрос: что делать?
Напрямую вносить изменения в файлы движка плохо по очевидным причинам:
- заказчик теряет возможность обновления версий движка. Движок развивается - заказчик стоит на месте, и его сайт устаревает.
- поведение движка становится всё менее стандартным, и движок всё более превращается в самописный. Самописный движдок дороже в сопровождении (программистам надо вникать в него), менее стабилен в работе (самописный код тестируется ровно на одном самописном сайте, а не всей клиентской базой тиражируемого движка)
Что же делать?
Хороший тиражируемый движок в той или иной степени поддерживает модульность своей архитектуры: можно менять функциональность движка, добавляя к нему модули (плагины, компоненты, расширения, темы, шаблоны - терминология зависит от конкретного движка).
Но я не встречал ни одного движка, кроме Magento, который позволял бы точечно менять поведение системных объектов ядра движка из стороннего модуля.
Происходит это классическим объектно-ориентированным способом: наследуетесь от системного класса, перекрываете требуемый метод системного класса и свой класс-наследник помещаете в свой модуль, который затем подключаете к Magento.
(Всё это волшебство становится возможным благодаря применению отличных паттернов проектирования при разработке архитектуры Magento. В частности, все объекты (и системные, и подключаемых модулей) создаются с применением паттерна Factory. Это делает возможным переопредетить тип создаваемого объекта: например, с системного класса-родителя на класс-потомок стороненнего модуля.)
Преимущества такого подхода гигантские:
- Все правки ядра сосредоточены в одном месте - стороннем модуле, код которого чётко отделён от кода движка.
- Этот модуль можно подключать и отключать в любой момент.
Приведу пример. Внёс программист изменения в программный код интернет-магазина. Вроде всё работает. Потом вдруг обнаруживается критический дефект. Что делать? В другом движке пришлось бы откатывать внесенные изменения, взяв предыдущую версию кода из системы контроля версий. Этот процесс достаточно трудоёмок (может занять несколько часов работы программиста).
В Magento же достаточно зайти в админку и отключить конфликтный модуль.
В следующей статье, сугубо технической, для программистов, я расскажу, как посредством своих модулей вносить изменение в поведение движка Magento.
