Как начать разработку крупного, нетипичного проекта. Практическое пособие

    image


    Выбор платформы для бекенда

    Чтобы создать качественное и производительное Web-приложение, необходимо уделить должное внимание выбору платформы для разработки. Этим нужно заняться сразу же после того, как вы ознакомились, какие задачи должно выполнять это приложение.


    В данном случае, немаловажным фактором в техническом задании была предположительно высокая нагрузка на сервис. На рынке есть много хороших инструментов, с помощью которых можно решить поставленную задачу. Некоторые мы используем в разработке, но в этот раз выбор все-таки пал на Yii2.


    Если более детально рассматривать этот фреймворк, можно выделить ряд преимуществ:


    • Высокая производительность;
    • Удобство в работе с базами данных;
    • Кэширование страниц и отдельных фрагментов;
    • Перехват и обработка ошибок;
    • Аутентификация и авторизация;
    • Использование миграции базы данных облегчает командную работу.

    Установив шаблон advanced, мы уже получаем некоторые необходимые нам возможности, такие как формы регистрации пользователей и входа на сайт с функциональностью восстановления забытого пароля. Еще одно значительное преимущество этого шаблона, – это то, что приложение делится на frontend (пользовательская часть) и backend (часть администратора).


    При проектировании структуры приложения были принято решение разнести логические части на модули. Хотя некоторые модули и зависят друг от друга, модульное программирование позволяет удобно расширять и поддерживать код.


    Выбор платформы для фронтенда

    Так как наше приложение предполагает наличие множества интерактивных элементов управления, которые будут взаимодействовать друг с другом и с сервером, решили, что jQuery, который идет в коробке c шаблоном advanced, нужно усилить, добавив на фронтэнд AngularJS (потому что Angular для этого и создавался). Он позволяет вводить темплейтинг, не нарушая структуру самого HTML-документа.


    Тем самым мы можем сделать верстку, потом добавить темплейт-атрибуты, но верстальщик сможет продолжать работу с документом так, как если бы это был статический HTML. То есть очень просто изменять дизайн в процессе разработки, не опираясь на определенную верстку и атрибуты class, либо id html-элементов. Это большой плюс, особенно, если хочется разделить работу над пользовательским интерфейсом. Эта особенность помогла нам распределить задачи в командной работе. Один человек верстает, второй вводит байндинги и привязывает вьюмодель к бекенду.


    К преимуществам использования AngularJS можно отнести:


    • Довольно низкий порог вхождения;
    • Легкость построения сложных цепей зависимостей;
    • Параллельная работа в команде;
    • Возможность по максимуму использовать HTML атрибуты, минимизируя javascript код;
    • Хорошая поддержка со стороны компании и сообщества;
    • Простота работы с REST.

    Реализация модульной структуры

    Надеемся, что вы знакомы с Yii2 и уже писали хотя бы несколько приложений на этом фреймворке. Далее будем обращать внимание только на те решения, которые мы применили в нашем проекте.


    Мы использовали шаблон advanced, ряд преимуществ которого был описан выше. Но уже на этом этапе, при установке yii2-app-advanced через composer, многие пользователи сталкиваются со следующей ошибкой при попытке открыть сайт в браузере:


    The file or directory to be published does not exist: D:\OpenServer\domains\yii2-app-advanced/vendor\bower/jquery/dist
    image
    Необходимо установить composer asset plugin и решить проблему следующими командами:


    cd /path/to/your/project
    composer global require "fxp/composer-asset-plugin:~1.1"
    composer update

    Также проверьте, есть ли такие строки в вашем composer.json файле:


    {   
        "extra": {
            "asset-installer-paths": {
                "npm-asset-library": "vendor/npm",
                "bower-asset-library": "vendor/bower"
            }
        }
    }

    Так как мы организовали модульную структуру приложения, первым делом добавим alias для нашей папки с модулями в файл \common\config\bootstrap.php


    <?php
    Yii::setAlias('@common', dirname(__DIR__));
    Yii::setAlias('@frontend', dirname(dirname(__DIR__)) . '/frontend');
    Yii::setAlias('@backend', dirname(dirname(__DIR__)) . '/backend');
    Yii::setAlias('@console', dirname(dirname(__DIR__)) . '/console');
    Yii::setAlias('@modules', dirname(dirname(__DIR__)) . '/modules');

    Теперь все модули, которые мы будим писать, будут располагаться в папке /modules.


    Настало время создать первый модуль в этом проекте. Начнем с модуля, который будет отвечать за отображение основных страниц сайта, таких как “Главная страница”, страница контактов, 404 страница, страница “About us”. Для этого мы можем воспользоваться Gii генератором, который может написать код за нас.


    Переходим в вашем браузере по ссылке и попадаем на главную страницу генератора.
    image
    На данном этапе вы, скорее всего, уже создали базу данных и внесли соответствующие настройки для подключения к ней в файл конфигурации \environments\dev\common\config\main-local.php


    …
       'components' => [
            'db' => [
                'class' => 'yii\db\Connection',
                'dsn' => 'mysql:host=localhost;dbname=your-db-name',
                'username' => 'db-user-name',
                'password' => 'db-user-password',
                'charset' => 'utf8',
            ],
    …

    Нажимаем кнопку Start в блоке ‘Module Generator’ и попадаем в просмотр генерации модуля.


    Заполняем два инпута следующим образом:


    Module Class:
    modules\site\Module
    Module ID:
    site

    Жмем кнопку ‘Preview’, затем ‘Generate’ и смотрим, как создаются файлы первого модуля. Осталось только подключить его в конфигурационном файле так, как подсказывает Gii генератор.


    Добавим следующие строки в файл \common\config\main.php


      ......
        'modules' => [
            'site' => [
                'class' => 'modules\site\Module',
            ],
        ],
        ......

    И подправим конфигурационный файл фронтенда \frontend\config\main.php, добавив строчку:


     ......
        'defaultRoute' => 'site/site/index',
        ......

    Она определяет то, что главная страница у нас находится по роуту 'site/site/index', то есть в нашем модуле Site.


    В этом же файле мы удаляем строку


    'controllerNamespace' => 'frontend\controllers'

    Это необходимо сделать, потому что теперь в каждом модуле будут определяться свои неймспейсы для контроллеров. Поговорим об этом далее.


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


    …
    site
    -- controllers
    -- -- backend
    -- -- frontend
    -- models
        -- -- backend
        -- -- frontend
        -- views
        -- -- backend
        -- -- frontend
    …

    Соответственно, имеющиеся уже у нас в модуле контроллер и view, необходимо перенести в соответствующие папки frontend и не забыть изменить namespace в контроллере на namespace modules\site\controllers\frontend;


    Код файла модуля мы перепишем так, чтобы было понятно, к какому контролеру ему обращаться при работе на фронтенде, и к какому при работе в панели администратора. Таким образом на фронтенде он будет обращаться к контроллеру в папке /modules/site/controllers/frontend, а при работе в админ-панели задействовать контроллер в папке /modules/site/controllers/backend.


    <?php
    
    namespace modules\site;
    
    /**
     * site module definition class
     */
    class Module extends \yii\base\Module
    {
        /**
         * @inheritdoc
         */
        public $controllerNamespace = 'modules\site\controllers\frontend';
    
        /**
         * @var boolean Если модуль используется для админ-панели.
         */
        public $isBackend;
    
        /**
         * @inheritdoc
         */
        public function init()
        {
            parent::init();
    
            // Это здесь для того, чтобы переключаться между frontend и backend
            if ($this->isBackend === true) {
                $this->controllerNamespace = 'modules\site\controllers\backend';
                $this->setViewPath('@modules/site/views/backend');
            } else {
                $this->setViewPath('@modules/site/views/frontend');
            }
        }
    }
    

    А для того, чтобы настроить доступ к модулю site на бекенде, нужно обозначить его в конфигурационном файле бекенда \backend\config\main.php следующим образом:


    ...
       'modules' => [
            'site' => [
                'isBackend' => true,
            ]
        ],
    ...

    и заменить строку


    'controllerNamespace' => 'backend\controllers',

    на


    'defaultRoute' => 'site/site/index',

    Теперь можно создавать контроллеры в папке /modules/site/controllers/backend для бекенда. Я перенесу контроллер SiteController.php с папки /backend/controllers в /modules/site/controllers/backend и заменю в нем namespace, соответственно.


    После проведения манипуляций по рефакторингу существующих контроллеров, моделей и представлений и переноса их в наш модуль site, он стал преображаться и приобретать следующий вид:
    image
    B этой статье я постарался изложить все плюсы выбранных нами технологий для интересного крупного проекта, предложил способ реализации модульного приложения на Yii2 фреймворке. Это первый пост из цикла статей, в которых я хочу поделиться с вами всеми теми способами, которые мы использовали при решении различного рода нетипичных задач при разработке данного проекта.


    В следующей статье я опишу настройку роутинга и создания URL при помощи urlManager для каждого модуля по отдельности. А также разложу по полочкам процесс создания собственных правил для специфических URL с помощью написания класса, который расширяет UrlRuleInterface.


    Спасибо за внимание!


    Материал подготовлен: greebn9k(Сергей Грибняк), pavel-berezhnoy(Павел Бережной), silmarilion(Андрей Хахарев)

    Поделиться публикацией
    Комментарии 64
      +8
      Возможно, давным-давно на меня повлиял dreamviewer, но я никогда не пользуюсь генераторами кода. Не вижу ничего плохого в том, что бы в ide сделать шаблоны и самому создавать модели, контроллеры, etc. А вообще зашел почитать про то, как angular работает с yii, но ничего не увидел.
        0
        Действительно, в создании моделей руками ничего плохого нет. Но Gii довольно-таки неплохо экономит время разработчика, имхо.
          0

          только тогда когда "модель" это тупое объектное представление рядов таблицы. Ну то есть приложение по сути просто CRUD. Таких большинство, и потому в этом нет ничего плохого, но как только что-то сложнее и нужно заниматься "моделированием" бизнес логики с gii и подобными подходами разработчики быстро превращают код в неудобную кашу (пытаясь подогнать все под кодогенерацию а не под логику работы системы).

            0
            Тут от рук разраба зависит. Если быстро надо собрать тупую админку и потом руками дописать пару связей, как это нужно для 95% проектов, то годится и так.
          0
          По мне, лучше генераторы кода, чем визуальные редакторы — они более ограничены, а потому, более предсказуемы. Визуалки же (по крайней мере, раньше так делали) генерят ужасную разметку и код.
          Но в целом, и то, и другое — для быстрого старта, все равно всегда приходится много перепиливать до рабочего состояния.
          Лично я вообще редко, за некоторым исключением, пользуюсь генераторами (scaffolding), предпочитая писать все руками, пусть ценой очень долгого времени и затраченных усилий.
            0
            gii — это не dreamviewer. Он гораздо проще и оперирует ограниченым количеством шаблонов.
            gii наиболее удобен в создании моделей по таблице в базе данных, т.к. сразу создаётся набор правил валидации, методы для relations и phpdoc со списком полей.
              +1
              Может имеется ввиду Dreamweaver?
                0
                Да, просто это было лет 10 назад, не помню как правильно пишется.
                0
                Особенно хорошо самому писать модель с таблицы с 30 полями и 15 отношениями.
                  +1
                  В своих проектах меняю исходные шаблоны gii, на основе которых он генерирует классы, так, как мне удобно. Значительно ускорят разработку. В любом случае, он умеет лишь генерировать скелет класса, не более. Ничего плохого в этом не вижу.
                  +1
                  один вопрос — зачем использовать оверхед с Module если можно сделать также как в yii2 advanced template?
                    0
                    Как я писал в статье, приложение разделялось на модули, для того чтоб его было удобней разрабатывать и поддерживать код. Можно разделить разработку приложения помодульно на каждого разработчика. А также готовые модули возможно переиспользовать от проекта к проекту.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      +7
                      а как сюда angular вписывается?
                        0
                        Чем jQuery можно усилить? Аngular'ом?
                        Помоему в AngularJS используется light версия для работы с DOM на основе jQuery.
                        Я думаю встроенных возможностей Angular достаточно для этого. А если нужны анимации и прочее… используйте плагины Angular, следите за ними через bower, npm итп…
                          +1
                          > «можно выделить ряд преимуществ: ...»

                          Это не преимущества («превосходство в сравнении с кем-чем-н. другим») Yii, так как это есть во всех современных php фреймворках. И Некоторые превосходят (объективно или субъективно) Yii по части изложенных пунктов.

                            +3

                            Для выбора технологий реализации "нетипичного" проекта, следует четко понимать, в чем именно нетипичность этого проекта, и как эти технологии с этой нетипичностью соотносятся. Если "типичные" и вполне заурядные технологии вам полностью подходят, как следует из статьи, то что там "нетипичного"? Мой личный опыт работы с "нетипичными" проектами кричит о том, что Angular использовать НЕ стоит, если "нетипичность" выше среднего.

                              +1
                              Если она выше среднего то в общем то наверное и фреймворк общего назначения вряд ли подойдет.
                              Тут уже нужно брать разве что отдельные библиотеки типа ORM, DI и прочие, а архитектуру пилить исходя из «нетипичности» проекта.
                                +2
                                В чем же нетипичность?
                                И технологии вполне себе типичные — jQuery, Angular и Yii — наверное, наиболее популярные фреймворки.
                                  +1
                                  Мой личный опыт работы с "нетипичными" проектами кричит о том

                                  А вы как ангуляр готовили? Жирные контроллеры, или маленькие компоненты и логика в сервисном слое? Писали тесты?


                                  А про нетипичность и т.д. это лишь для красивого словца в заголовке, ибо ничего нетипичного я в статье не увидел.

                                  0
                                  Заголовок данной статьи почему-то мне сказал о том, что я тут увижу gii форм. Т.е. генератор кода формы с ангуларовским контроллером. Вот печаль, не увидел. Стоковый gii форм вещь полезная, но на выходе простые формы. Да, с валидацией, но без механики. Например, скрыть/показать поле при установке чекбокса. Для ангулара это в принципе одна директива. Но для этого нам нужно создать контроллер, задать модели полям. Если мы скрываем обязательное поле, значит придётся переделывать серверную и клиентскую валидацию yii. В общем уже не вписывается в идеологии gii «Ахалай-махалай, по модельке сгенерись». А если бы генератор форм это сам всё делал? Нам бы оставалось только сосредоточиться на разработке удобного интерфейса формы, где что-то скрывается, показывается итд. Может быть вы хотели написать об этом, но забыли? Где у вас симбиоз йии и ангулара?
                                    +2
                                    Вот печаль, не увидел.

                                    И слава сатане что не увидели, это ж ад был бы. Для кодогенерации во фронтэнд мире есть штуки намного удобнее чем Gii который ориентирован исключительно на CRUD контроллеры Yii. Для ангуляра же выгоднее использовать форм билдеры вроде angular formly.


                                    Ну и да, когда речь идет о нестандартном и нетипичном проекте как-то смешно немного Gii использовать.

                                      0
                                      Почему же ад, angular formly я не использовал, но получение от gii, который между прочем ориентирован не только на CRUD контроллеры Yii (в теории, опираясь на само направление кодогенерации), кода формы + ангуларовский контроллер — ИМХО, очень даже рай. А сможет ли angular formly забрать у модельки тип данных, или длину, или любой другой валидатор, например exist? Я думаю, что нет, Вы будете это руками писать, так или иначе. Я же имел в виду пропускать этот шаг, ведь это уже есть в модельке. Или я Вас не так понял?
                                        0
                                        А сможет ли angular formly забрать у модельки тип данных, или длину, или любой другой валидатор, например exist?

                                        1) валидатор exists не нужен
                                        2) если у вас строчка в базе напрямую проэцируется на объекты, оттуда проэцируется на ресурс API и оттуда на форму ангуляра… то может стоит задуматься о том что вам вообще бэкэнд на Yii не нужен? например взять firebase и не париться, покрывает где-то 70%-80% всех проектов связанных с API.

                                    –1
                                    А это норм создавать модели для форм?)
                                      –9
                                      как сделать говно? нужно взять одно говно и смешать с другим говном.

                                      > Чтобы создать качественное и производительное Web-приложение,

                                      на php фреймворке? серъезно?

                                      > необходимо уделить должное внимание выбору платформы для разработки.

                                      что тут выбирать? бери Go или phoenixframework и шуруй

                                      > высокая нагрузка на сервис.

                                      на php фреймворке? серъезно?

                                      или высокая нагрузка от слова выское и не оптимальное потребление ресурсов? это да с PHP всегда пожалуйста
                                        +3
                                        Серьёзно.
                                          +3
                                          Аватарка вам подходит
                                          +3
                                          «Довольно низкий порог вхождения»

                                          Очень ошибочное впечатление об Ангуляре, покрайне мере 1.* версии

                                            0
                                            Очень ошибочное впечатление об Ангуляре, покрайне мере 1.* версии

                                            Ну хз, у меня для его использования хватило недели чтения доки в свое время (2012-ый год). Сейчас с angular1.5, компонентами, стайлгайдами и т.д. ситуация только улучшилась.

                                              0
                                              Странно, в первой версии как раз сложных вещей нет, другое дело вторая.
                                              +2
                                              Начинать новый проект на Angular 1.x немного странно, с учетом того, что версия 2 принципиально другая и вся текущая разработка направлена именно на нее. Про Yii2 ничего не могу сказать, мне вообще непонятны люди пишущие на PHP.
                                                0
                                                с учетом того, что версия 2 принципиально другая и вся текущая разработка направлена именно на нее.

                                                посмотрите внимательно на angular 1.5+ Некоторые фичи, такие как компоненты даже в 1.3+ доступны. То есть если брать 1.0 и 2.0 — различия конечно могут напугать. Но версии 1.0 уже 4 года.


                                                Если вам интересно как выглядят проекты на современном ангуляре (то есть последние версии и последние подходы) рекомендую глянуть этот репозиторий: https://github.com/martinmicunda/employee-scheduling-ui

                                                  +4
                                                  а мне непонятны люди, критикущие PHP, не аргументируя это
                                                    +4

                                                    Ну это типа модно критиковать PHP без аргументации, просто "потому что". а то, что PHP — самый быстрый в мире интерпретируемый язык без JIT (который должен быть в 7.2 по планам) с одной из лучших объектных моделей — их не волнует.

                                                    –1
                                                    Зачем вообще оставлять свои высеры в хабе о PHP, если на PHP не пишете?
                                                      0

                                                      Что бы происходил обмен опытом между разными комьюнити.


                                                      Например автор комментария вполне поделу выразил свое мнение относительно выбора версий фреймворка (субъективное прошу заметить). То есть все по делу и т.д. а вот вашы "высеры" несут исключительно деструктивный характер.

                                                    –3

                                                    2016 год на дворе. jQuery?! Angular?! Где React? Где Webpack? Где Node.js?

                                                      +2
                                                      Где React? Где Webpack? Где Node.js?

                                                      Остались в 2014-м.

                                                      +3
                                                      AngularJS вроде как создавался для создания SPA, и последние сборщики собирают все в один js-файл, включая и темплейты. Это значительно ускоряет работу веб-приложения, а на сервере достаточно сделать API-интерфейс. В этом случае есть четкое разделение фронтенда и бекенда. Тогда использовать шаблонную систему Yii нет смысла. Полезность конструкторов форм Yii тоже под вопросом. А если большинство плюшек Yii не будут использоваться, то можно выбрать что-нибудь полегче.
                                                      У автора, как я понял, Angular используется не по назначению, соответственно, многие его плюсы не задействованы. Не нашел, почему такой «крупный нетипичный проект» будет быстрее или лучше обычного сайта.
                                                        0

                                                        Не используемые плюшки лишь занимают место на диске (пару мегабайт). На используемые плюшки они никакого влияния не оказывают.

                                                        0
                                                        Разрабатываю проект на AngularJS + backend. Долго думал и тестировал какой же выбрать backend. Поставил yii2 и оказалось головной болью, так как вся логика в базе данных, работа через pipeline-функции, все данные обрабатываются через процедуры, нет прямого доступа к таблицам.
                                                        В итоге остановился на Phalcon: phalconphp.com/ru. Действительно быстрый и удобный.
                                                        Пишу на 1.5.7 Angular, было страшно разрабатывать проект на Angular 2 Beta, решил завершить на ветке 1.х, а потом мигрировать на 2.х

                                                        Еще вначале года React не пользовался популярностью, а теперь с чего вдруг на него такая мода пошла?
                                                          +1
                                                          Мигрировать с Angular 1 на Angular 2 === написать проект заново.
                                                            –1

                                                            Абсолютно голословное утверждение.


                                                            Это больше зависит от того как написано приложение и каков уровень связанности с фреймворком. Нормальные приложения (то есть где логика не размазана по километровым контроллерам) портируются весьма просто. Особенно если проект начинался на актуальных версиях ангуляра.

                                                              0
                                                              Не буду с вами спорить, вы конечно же видели вот эту страницу: https://angular.io/docs/ts/latest/cookbook/a1-a2-quick-reference.html
                                                              При переходе всего лишь нужно исправить все темплейты — а это все ангуляровские директивы, биндинги (в старых версиях ангуляра, кстати, было, так же, как в ангуляре 2, то есть не нужно было писать vm.variable); прописать декораторы всем контроллерам, да и вообще значительно переделать все контроллеры. Добавить bootstrap. При этом ангуляр2 написан на TypeScript, и если ваш проект на js, то ангуляровский ts будет периодически напоминать о себе.
                                                                –1
                                                                При переходе всего лишь нужно исправить все темплейты — а это все ангуляровские директивы

                                                                Это не так много на самом деле. Заменить ng-hide="$ctrl.someExpression" на [hidden]=someExpression выглядит не сильно сложно. Есть конечно и более интересные штуки вроде ngIf* но по большей части это может только стили чуть сломать если все на каскадирование было завязано.


                                                                прописать декораторы всем контроллерам

                                                                в моих проектах нет контроллеров, есть только компоненты. В последний раз контроллеры писал год назад.


                                                                прописать декораторы всем контроллерам

                                                                тип вместо ngApp? мне казалось серьезные дядьки и так его не используют. Ну и опять же это не сильно сложно. Особенно если пишешь проект с оглядкой на 2-ую версию как автор ветки.


                                                                и если ваш проект на js, то ангуляровский ts будет периодически напоминать о себе.

                                                                как именно? Можете привести примеры ибо это действительно было бы интересно. Я к сожалению на babel + angular2 не достаточно много писал что бы говорить что "никаких проблем".

                                                                  +1
                                                                  как именно? Можете привести примеры ибо это действительно было бы интересно

                                                                  Это вопрос удобства — на stackoverflow и прочих ресурсах все вопросы/ответы на TypeScript. Если нужно залезть в исходники AngularJS, то там тоже ts. В данный момент документация тоже в большинстве своем на ts. Если при этом сам пишешь на JS, то переключаться туда-сюда лично мне не комфортно. Поэтому, начав разрабатывать на второй версии, я выбрал именно TypeScript. А текущие проекты, которые написаны на первом ангуляре, переносить на второй не планирую в ближайшем будущем.
                                                                    0

                                                                    ну если брать JS + babel то психологически разница между TS версией уже не такая большая. Информация о типах опциональна и мы можем большую часть проекта писать как обычно (с плюшками вроде неявной установки пропертей в конструкторе, которая мне дико нравится), а важные вещи с прописанными типами.


                                                                    Ну а в целом да, я тоже по итогу на TS пишу, по тем причинам которые вы описали. Но правда мне нравится, и я считаю это плюсом.

                                                              +1
                                                              Не бывает волшебной кнопки, по нажатию которой проект мигрирует с минорной версии на мажорную. И не вижу смысла гнаться за последней версией, которая еще была в бета-версии. Можно просто облегчить себе переход, использую стайл-гайды.
                                                              Так, для ознакомления, посоветовал бы выбрать из
                                                              Todd Motto's: https://github.com/toddmotto/angularjs-styleguide
                                                              John Papa's: https://github.com/johnpapa/angularjs-styleguide
                                                              Minko Gechev's: https://github.com/mgechev/angularjs-style-guide
                                                              Сам пишу придерживаясь стиля John Papa.
                                                                0
                                                                Сейчас начинаем писать админки для rest сервисов, выбираем между angular 1 и angular 2. Насколько он production-ready? Начинали с ранних версий ангуляра, к тому моменту, как написали для себя достаточно компонентов за годы, он как-то успел устареть:). Большой ли профит от перехода на angular 2? Как бы он тоже не устарел через два месяца… Проходили это все в связке с bootstrap(css) :)
                                                                  0
                                                                  Насколько он production-ready?

                                                                  Ну мы недавно небольшой проектик для пробы пера на нем написали — весьма неплохо вроде бы все. Все еще ощущается легкая нехватка библиотек но на данный момент почти все нужное есть.


                                                                  к тому моменту, как написали для себя достаточно компонентов за годы, он как-то успел устареть:)

                                                                  Не сказал бы что ангуляр устарел. Те подходы которые использовали устарели, но как бы на angular 1.5+ можно использовать все то что есть в ng2 в плане подходов. Особенно если писать с typescript всякими.


                                                                  Большой ли профит от перехода на angular 2?

                                                                  Профит от angular2 будет для реально больших приложений. Для админок профита лично мы не увидели. А вот там где нужно будет делать уже server-side пререндеринг второй будем брать уже второй ангуляр.

                                                                    0
                                                                    Выбирая между первым и вторым ангуляром, для небольшого проекта с админкой я выбрал Angular 1.5. Там есть все, что нужно, плюс я его дольше знаю, и разработка идет быстрее — считаю, что это основной профит. Но это для маленького проекта, про большой проект ничего сказать не могу.
                                                                    Хотя нет, могу — когда несколько месяцев назад писал проект на Angular2, пару раз пришлось весь код перелопачивать и частично менять его из-за изменений в Angular. Тогда он был бетой, я был готов к этому. Сейчас он RC, вроде изменений должно быть по минимуму, но кто знает…
                                                                  +1
                                                                  А что за логика в БД? Что за pipeline-функции? Какие процедуры?

                                                                  Работал как с PhalconPHP, так и с Yii/Yii2. PhalconPHP проигрывает Yii2 в роли REST сервера. Phalcon можно конечно и подтянуть, но из коробки (да и в целом архитектура) Yii2 больше подходит для REST-сервиса.
                                                                    0
                                                                    весь рабочий процесс(электронный документооборот). Pipeline-функция, грубо, это функция, которая возвращает таблицу (BD oracle).
                                                                    т.е. запрос вида
                                                                    SELECT * FROM TABLE(users(ID))
                                                                    Я не смогу использовать Active Record в таком случае.
                                                                    В phalcon проще стартануть, но при одинаковых условиях, phalcon быстрее yii2, как по мне. Ничего лишнего больше не надо, я в Phalcon использую только микро-фреймворк.
                                                                      +1
                                                                      Если честно, не приходилось работать с базой Oracle, поэтому не буду спорить на счёт функционирования Yii2 и этой бд, тут нам SamDark нужен. Но если вы используете Phalcon только как Micro и вас всё устраивает, то тогда всё хорошо и Phalcon действительно лучше подходит.

                                                                      Увы, мне пришлось убежать с Phalcon на Yii2 именно в тот момент, когда мой проект стал перерастать в нечто большее, чем простой сайтик :)
                                                                        0
                                                                        А вы используете yii2 только как Rest?
                                                                        Какие проблемы возникли, которые повлияли на решение о переходе на yii2?
                                                                          +1
                                                                          Во первых, Yii2 имеет значительно большее сообщество, нежели Phalcon, а значит искать решения или готовые библиотеки будет гораздо проще.
                                                                          Во вторых, у Yii2 более богатая библиотека helper'ов.
                                                                          В третьих, у AR Yii2 есть поддержка realtions, запросов с Join и так далее. У Phalcon такого нет. У Yii2 же есть ->joinWith, который творит всю магию.
                                                                          В четвёртых, у PhalconPHP при обновлении модели, сохраняются все поля. У Yii2 есть понятие «гразные атрибуты», которые и обновляются.
                                                                          В пятых, у Yii2 есть отличный механизм поведений, внутри которых доступны все события модели.
                                                                          В шестых, у Yii2 сервисы конфигурируются удобнее, чем у Phalcon (здесь речь про мержи массивов с описанием компонентов перед тем, как компонент будет реально создан). У Phalcon такое сделать сложнее.
                                                                          В седьмых, у Yii2 есть функциональный встроенный механизм миграций. На Phalcon мне пришлось впиливать поддержку Phinx migrations, поскольку родной механизм «такой себе».
                                                                          В восьмых, у Yii2 есть Rbac, как на базе файловой системы, так и в БД. У Phalcon, конечно, есть ACL, но у Yii2 это всё так классно вмешано в логику контроллеров через поведения проверки доступа.
                                                                          В девятых, если тебе нужно понять, почему какой-то кусок фреймворка не работает или, что ещё хуже, тебе нужно его изменить, то в абсолютном большинстве случаев ты идёшь на github, смотришь код, видишь там private/final, плачешь, копируешь Zephir код и идёшь его портировать обратно на PHP в своём приложении. Я это высосал не из пальца, я писал тэгируемый кэш и я нашёл очень много тёмных мест внутри исходников Phalcon.

                                                                          Сходу вспоминаются эти штуки. Вся вышеописанная критика актуальна для Phalcon 1.3.*. Что сейчас творится на 2.0.* я не знаю, но, емнип, новых фич они не добавляли, а просто переписали его на Zephir. Нет, всё вышеописанное не говорит, что мол «Phalcon ненужон», но всё же он больше мне видится для простых микросервисов, либо как основа для какой-то массивной наработки поверх него, которая решала бы большинство его же проблем.
                                                                        0
                                                                        Если так хочется (или необходимо) использовать такие специфичные вещи, то зачем брать фреймворк (yii2), основной элемент которого, такое не поддерживает?
                                                                          0

                                                                          Вполне можно написать модельки и из заполнение из базы в виде репозитория, внутри которого query builder.

                                                                            0
                                                                            Yii рассматривался как rest для angular, так как хотел изучить эти 2 фреймворка. А нет лучше методов изучения, как сразу практика.
                                                                            Потом решил перенести все в бд, оставить angular и с чистого написать свой rest. Но время поджимало и на дворе 2016 год, бессмысленно писать с 0, решил использовать phalcon.
                                                                              0
                                                                              Yii как rest — ничего необычного.
                                                                              Но перенос логики в БД — нетипичная задача. Как в принципе в разработке, так и для Yii. Особенно для Yii, где половина работы с БД завязана на ActiveRecord.
                                                                              Кстати:
                                                                              > все данные обрабатываются через процедуры, нет прямого доступа к таблицам
                                                                              Есть удобные query и command. Вот только придётся работать с массивами. Неудобно. но не смертельно.
                                                                              Или делать свою реализацию (Base)ActiveRecord, которая будет выполнять все операции с использованием view и процедур.

                                                                              Если не секрет, что стало решающим в пользу переноса всего в БД?
                                                                            0

                                                                            Теоретически можно завести VIEW и его уже использовать в AR. Но вообще это очень специфичная задача, для которой AR как-то и не подходит...

                                                                              0
                                                                              Работал с одним проектом на Yii2 + Postgres, там тоже логика была в базе. Модели можно было генерировать из типов (которые CREATE TYPE). Неудобно конечно, приходится вручную писать сохранение/загрузку, и модель становится больше похожа на репозиторий. Но думаю, если унифицировано именовать функции в БД, то можно сделать общую базовую AR-модель с findBySql() для чтения и полностью переопределенными методами для записи.
                                                                          0
                                                                          удалить

                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                          Самое читаемое