Comments 8
Рад, что yii идет в массы. Достойнейший фреймворк, а вакансии были в основном лишь на Zend и Symfony
1) спасибо за интересную статью
2) ждем продолжения для описания «почему были выбранны именно эти технологии» (меня интересует в разрезе выбора phing)
чисто организационно:
1) как много времени уходит на ревью и рефакторинг кода? при данной организации кода есть очень большие риски, что разработчик приладит функционал в не тот слой, в который надо.
2) организация проекта в таком виде шла с нуля или приходилось отталкиваться от существующих рудиментов?
2) ждем продолжения для описания «почему были выбранны именно эти технологии» (меня интересует в разрезе выбора phing)
чисто организационно:
1) как много времени уходит на ревью и рефакторинг кода? при данной организации кода есть очень большие риски, что разработчик приладит функционал в не тот слой, в который надо.
2) организация проекта в таком виде шла с нуля или приходилось отталкиваться от существующих рудиментов?
Очень приятно, что статья понравилась. Спасибо. Будем писать еще.
По вопросам:
1. У нас существует программа адаптации для новых сотрудников, поэтому есть время разобраться в структуре проектов, посмотреть как реализован существующий функционал
По опыту, вопросы чаще возникают по таким определениям в yii как компонент, расширение, виджет, хелпер, модуль. Как лучше/правильнее их применять и где.
На ревью времени уходит не больше, чем на обычные yii-проекты, функциональные блоки которого уже хорошо известны команде.
Для рефакторинга образуется больше возможностей, так как вся бизнес логика по работе с сущностью предметной области сосредоточена в расширении и его моделях. Работа с расширением идет через его API. Внутреннюю реализацию мы можем рефакторить, главно соблюдать заявленное API :)
2. Организация проектов в таком виде шла с нуля. Немногочисленные оставшиеся рудименты постепенно переводятся на новую архитектуру.
По вопросам:
1. У нас существует программа адаптации для новых сотрудников, поэтому есть время разобраться в структуре проектов, посмотреть как реализован существующий функционал
По опыту, вопросы чаще возникают по таким определениям в yii как компонент, расширение, виджет, хелпер, модуль. Как лучше/правильнее их применять и где.
На ревью времени уходит не больше, чем на обычные yii-проекты, функциональные блоки которого уже хорошо известны команде.
Для рефакторинга образуется больше возможностей, так как вся бизнес логика по работе с сущностью предметной области сосредоточена в расширении и его моделях. Работа с расширением идет через его API. Внутреннюю реализацию мы можем рефакторить, главно соблюдать заявленное API :)
2. Организация проектов в таком виде шла с нуля. Немногочисленные оставшиеся рудименты постепенно переводятся на новую архитектуру.
Что-то после скриншота блинов захотелось… :)
Такая архитектура обычно закладывается на годы вперёд, и это правильно. Но есть нюанс: веб стал невменяемо динамичным, и скорость только нарастает: например, языки появляются и уходят за считанные годы (раньше были хотя бы десятилетия); про фреймворки вообще молчу.
Рассчитана ли ваша система на гетерогенность в плане языков/фреймворков? Например, если в какой-то момент через 2-3-4 года вы поймёте, что python-программистов на рынке стало больше и они лучше, чем php, а скорость обработки запросов в pypy в N раз выше чем в php. Или в результате коллективного умопомрачения мирового масштаба все начнут использовать Java/NodeJS/Go/ещё-что-нибудь. Не суть важно почему.
Рассчитана ли ваша система на гетерогенность в плане языков/фреймворков? Например, если в какой-то момент через 2-3-4 года вы поймёте, что python-программистов на рынке стало больше и они лучше, чем php, а скорость обработки запросов в pypy в N раз выше чем в php. Или в результате коллективного умопомрачения мирового масштаба все начнут использовать Java/NodeJS/Go/ещё-что-нибудь. Не суть важно почему.
Ну собственно чтобы разрабатывать систему на уровне интерфейсов и абстракций, а не на уровне конкретных реализаций и была заложена такая архитектура. Сейчас центральное место занимает Yii, но ничто нам не мешает начать плавный процесс перехода на другие ЯП или фреймворки, переписывая приложение за приложением и компонент за компонентом, следя чтобы не ломались интерфейсы между ними.
Собственно у нас это сейчас и происходит. Мы планомерно меняем высоконагруженные модули на PHP на серверные демоны на C++ c которыми работаем через Thrift протокол. А часть функциональных приложений прям напрашивается, чтобы их переписали на Erlang, т.к. от них требуется работа на распределенном кластере, высокая надежность и горячее обновление кода.
Собственно у нас это сейчас и происходит. Мы планомерно меняем высоконагруженные модули на PHP на серверные демоны на C++ c которыми работаем через Thrift протокол. А часть функциональных приложений прям напрашивается, чтобы их переписали на Erlang, т.к. от них требуется работа на распределенном кластере, высокая надежность и горячее обновление кода.
Возможно поздно спрашивать тут, спустя N-количество месяцев, но все же… В своем проекте вы отказывались от Yii ActiveRecords? И насколько у Вас большая нагрузка?
Спасибо за интересную статью! При чтении возник один вопрос, как устроено ваше АПИ? А именно как устроена передача объектов (данных) из нижних уровней, в верхние?
На сегодняшний день приложения на Yii чаще всего оперируют объектами ActiveRecords, как объектами предметной области. В данной слоистой архитектуре мы должны абстрагироваться от моделей, и инкапсулировать их в расширения. Т.е. мы не можем передавать их вверх другим слоям.
Значит необходимо создать некую коллекцию классов описывающих объекты предметной которая будет являться частью АПИ, и будет неизменна вне зависимости от реализации расширения.
Для вашего примера с UserExstentionAPI необходимо как минимум создать класс User, который после успешной авторизации будет передаваться вверх модулям-пользователям расширения.
Если я все правильно понимаю, то такой подход может значительно увеличить количество работы, и кода к примеру:
описали модели внутри модуля, реализовали бизнес логику, написали АПИ которое состоит из методов и нескольких классов (объектов данных), которые приблизительно повторяют модели, но ими не являются.
Так вот вопрос, как реализовано это у вас?
На сегодняшний день приложения на Yii чаще всего оперируют объектами ActiveRecords, как объектами предметной области. В данной слоистой архитектуре мы должны абстрагироваться от моделей, и инкапсулировать их в расширения. Т.е. мы не можем передавать их вверх другим слоям.
Значит необходимо создать некую коллекцию классов описывающих объекты предметной которая будет являться частью АПИ, и будет неизменна вне зависимости от реализации расширения.
Для вашего примера с UserExstentionAPI необходимо как минимум создать класс User, который после успешной авторизации будет передаваться вверх модулям-пользователям расширения.
Если я все правильно понимаю, то такой подход может значительно увеличить количество работы, и кода к примеру:
описали модели внутри модуля, реализовали бизнес логику, написали АПИ которое состоит из методов и нескольких классов (объектов данных), которые приблизительно повторяют модели, но ими не являются.
Так вот вопрос, как реализовано это у вас?
Sign up to leave a comment.
Слоистая архитектура на основе фреймворка yii