Comments 64
только тогда когда "модель" это тупое объектное представление рядов таблицы. Ну то есть приложение по сути просто CRUD. Таких большинство, и потому в этом нет ничего плохого, но как только что-то сложнее и нужно заниматься "моделированием" бизнес логики с gii и подобными подходами разработчики быстро превращают код в неудобную кашу (пытаясь подогнать все под кодогенерацию а не под логику работы системы).
Но в целом, и то, и другое — для быстрого старта, все равно всегда приходится много перепиливать до рабочего состояния.
Лично я вообще редко, за некоторым исключением, пользуюсь генераторами (scaffolding), предпочитая писать все руками, пусть ценой очень долгого времени и затраченных усилий.
gii наиболее удобен в создании моделей по таблице в базе данных, т.к. сразу создаётся набор правил валидации, методы для relations и phpdoc со списком полей.
Помоему в AngularJS используется light версия для работы с DOM на основе jQuery.
Я думаю встроенных возможностей Angular достаточно для этого. А если нужны анимации и прочее… используйте плагины Angular, следите за ними через bower, npm итп…
Это не преимущества («превосходство в сравнении с кем-чем-н. другим») Yii, так как это есть во всех современных php фреймворках. И Некоторые превосходят (объективно или субъективно) Yii по части изложенных пунктов.
Для выбора технологий реализации "нетипичного" проекта, следует четко понимать, в чем именно нетипичность этого проекта, и как эти технологии с этой нетипичностью соотносятся. Если "типичные" и вполне заурядные технологии вам полностью подходят, как следует из статьи, то что там "нетипичного"? Мой личный опыт работы с "нетипичными" проектами кричит о том, что Angular использовать НЕ стоит, если "нетипичность" выше среднего.
Тут уже нужно брать разве что отдельные библиотеки типа ORM, DI и прочие, а архитектуру пилить исходя из «нетипичности» проекта.
И технологии вполне себе типичные — jQuery, Angular и Yii — наверное, наиболее популярные фреймворки.
Мой личный опыт работы с "нетипичными" проектами кричит о том
А вы как ангуляр готовили? Жирные контроллеры, или маленькие компоненты и логика в сервисном слое? Писали тесты?
А про нетипичность и т.д. это лишь для красивого словца в заголовке, ибо ничего нетипичного я в статье не увидел.
Вот печаль, не увидел.
И слава сатане что не увидели, это ж ад был бы. Для кодогенерации во фронтэнд мире есть штуки намного удобнее чем Gii который ориентирован исключительно на CRUD контроллеры Yii. Для ангуляра же выгоднее использовать форм билдеры вроде angular formly.
Ну и да, когда речь идет о нестандартном и нетипичном проекте как-то смешно немного Gii использовать.
А сможет ли angular formly забрать у модельки тип данных, или длину, или любой другой валидатор, например exist?
1) валидатор exists не нужен
2) если у вас строчка в базе напрямую проэцируется на объекты, оттуда проэцируется на ресурс API и оттуда на форму ангуляра… то может стоит задуматься о том что вам вообще бэкэнд на Yii не нужен? например взять firebase и не париться, покрывает где-то 70%-80% всех проектов связанных с API.
> Чтобы создать качественное и производительное Web-приложение,
на php фреймворке? серъезно?
> необходимо уделить должное внимание выбору платформы для разработки.
что тут выбирать? бери Go или phoenixframework и шуруй
> высокая нагрузка на сервис.
на php фреймворке? серъезно?
или высокая нагрузка от слова выское и не оптимальное потребление ресурсов? это да с PHP всегда пожалуйста
Очень ошибочное впечатление об Ангуляре, покрайне мере 1.* версии
Очень ошибочное впечатление об Ангуляре, покрайне мере 1.* версии
Ну хз, у меня для его использования хватило недели чтения доки в свое время (2012-ый год). Сейчас с angular1.5, компонентами, стайлгайдами и т.д. ситуация только улучшилась.
с учетом того, что версия 2 принципиально другая и вся текущая разработка направлена именно на нее.
посмотрите внимательно на angular 1.5+ Некоторые фичи, такие как компоненты даже в 1.3+ доступны. То есть если брать 1.0 и 2.0 — различия конечно могут напугать. Но версии 1.0 уже 4 года.
Если вам интересно как выглядят проекты на современном ангуляре (то есть последние версии и последние подходы) рекомендую глянуть этот репозиторий: https://github.com/martinmicunda/employee-scheduling-ui
2016 год на дворе. jQuery?! Angular?! Где React? Где Webpack? Где Node.js?
У автора, как я понял, Angular используется не по назначению, соответственно, многие его плюсы не задействованы. Не нашел, почему такой «крупный нетипичный проект» будет быстрее или лучше обычного сайта.
В итоге остановился на Phalcon: phalconphp.com/ru. Действительно быстрый и удобный.
Пишу на 1.5.7 Angular, было страшно разрабатывать проект на Angular 2 Beta, решил завершить на ветке 1.х, а потом мигрировать на 2.х
Еще вначале года React не пользовался популярностью, а теперь с чего вдруг на него такая мода пошла?
Абсолютно голословное утверждение.
Это больше зависит от того как написано приложение и каков уровень связанности с фреймворком. Нормальные приложения (то есть где логика не размазана по километровым контроллерам) портируются весьма просто. Особенно если проект начинался на актуальных версиях ангуляра.
При переходе всего лишь нужно исправить все темплейты — а это все ангуляровские директивы, биндинги (в старых версиях ангуляра, кстати, было, так же, как в ангуляре 2, то есть не нужно было писать vm.variable); прописать декораторы всем контроллерам, да и вообще значительно переделать все контроллеры. Добавить bootstrap. При этом ангуляр2 написан на TypeScript, и если ваш проект на js, то ангуляровский ts будет периодически напоминать о себе.
При переходе всего лишь нужно исправить все темплейты — а это все ангуляровские директивы
Это не так много на самом деле. Заменить ng-hide="$ctrl.someExpression" на [hidden]=someExpression выглядит не сильно сложно. Есть конечно и более интересные штуки вроде ngIf* но по большей части это может только стили чуть сломать если все на каскадирование было завязано.
прописать декораторы всем контроллерам
в моих проектах нет контроллеров, есть только компоненты. В последний раз контроллеры писал год назад.
прописать декораторы всем контроллерам
тип вместо ngApp? мне казалось серьезные дядьки и так его не используют. Ну и опять же это не сильно сложно. Особенно если пишешь проект с оглядкой на 2-ую версию как автор ветки.
и если ваш проект на js, то ангуляровский ts будет периодически напоминать о себе.
как именно? Можете привести примеры ибо это действительно было бы интересно. Я к сожалению на babel + angular2 не достаточно много писал что бы говорить что "никаких проблем".
как именно? Можете привести примеры ибо это действительно было бы интересно
Это вопрос удобства — на stackoverflow и прочих ресурсах все вопросы/ответы на TypeScript. Если нужно залезть в исходники AngularJS, то там тоже ts. В данный момент документация тоже в большинстве своем на ts. Если при этом сам пишешь на JS, то переключаться туда-сюда лично мне не комфортно. Поэтому, начав разрабатывать на второй версии, я выбрал именно TypeScript. А текущие проекты, которые написаны на первом ангуляре, переносить на второй не планирую в ближайшем будущем.
ну если брать JS + babel то психологически разница между TS версией уже не такая большая. Информация о типах опциональна и мы можем большую часть проекта писать как обычно (с плюшками вроде неявной установки пропертей в конструкторе, которая мне дико нравится), а важные вещи с прописанными типами.
Ну а в целом да, я тоже по итогу на TS пишу, по тем причинам которые вы описали. Но правда мне нравится, и я считаю это плюсом.
Так, для ознакомления, посоветовал бы выбрать из
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.
Насколько он production-ready?
Ну мы недавно небольшой проектик для пробы пера на нем написали — весьма неплохо вроде бы все. Все еще ощущается легкая нехватка библиотек но на данный момент почти все нужное есть.
к тому моменту, как написали для себя достаточно компонентов за годы, он как-то успел устареть:)
Не сказал бы что ангуляр устарел. Те подходы которые использовали устарели, но как бы на angular 1.5+ можно использовать все то что есть в ng2 в плане подходов. Особенно если писать с typescript всякими.
Большой ли профит от перехода на angular 2?
Профит от angular2 будет для реально больших приложений. Для админок профита лично мы не увидели. А вот там где нужно будет делать уже server-side пререндеринг второй будем брать уже второй ангуляр.
Хотя нет, могу — когда несколько месяцев назад писал проект на Angular2, пару раз пришлось весь код перелопачивать и частично менять его из-за изменений в Angular. Тогда он был бетой, я был готов к этому. Сейчас он RC, вроде изменений должно быть по минимуму, но кто знает…
Работал как с PhalconPHP, так и с Yii/Yii2. PhalconPHP проигрывает Yii2 в роли REST сервера. Phalcon можно конечно и подтянуть, но из коробки (да и в целом архитектура) Yii2 больше подходит для REST-сервиса.
т.е. запрос вида
SELECT * FROM TABLE(users(ID))
Я не смогу использовать Active Record в таком случае.
В phalcon проще стартануть, но при одинаковых условиях, phalcon быстрее yii2, как по мне. Ничего лишнего больше не надо, я в Phalcon использую только микро-фреймворк.
Увы, мне пришлось убежать с Phalcon на Yii2 именно в тот момент, когда мой проект стал перерастать в нечто большее, чем простой сайтик :)
Какие проблемы возникли, которые повлияли на решение о переходе на yii2?
Во вторых, у 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 ненужон», но всё же он больше мне видится для простых микросервисов, либо как основа для какой-то массивной наработки поверх него, которая решала бы большинство его же проблем.
Вполне можно написать модельки и из заполнение из базы в виде репозитория, внутри которого query builder.
Потом решил перенести все в бд, оставить angular и с чистого написать свой rest. Но время поджимало и на дворе 2016 год, бессмысленно писать с 0, решил использовать phalcon.
Но перенос логики в БД — нетипичная задача. Как в принципе в разработке, так и для Yii. Особенно для Yii, где половина работы с БД завязана на ActiveRecord.
Кстати:
> все данные обрабатываются через процедуры, нет прямого доступа к таблицам
Есть удобные query и command. Вот только придётся работать с массивами. Неудобно. но не смертельно.
Или делать свою реализацию (Base)ActiveRecord, которая будет выполнять все операции с использованием view и процедур.
Если не секрет, что стало решающим в пользу переноса всего в БД?
Теоретически можно завести VIEW и его уже использовать в AR. Но вообще это очень специфичная задача, для которой AR как-то и не подходит...
Как начать разработку крупного, нетипичного проекта. Практическое пособие