Это позволяет и голый PHP с $_POST, но тем не менее

оу, а понимать что надо не везде - это сложно? )

Он это позволяет, говнокодеры юзают. А потом у людей, которые понимают, бомбит

так проблема в говнокодере

а еще можно архитектуру заранее продумать

и тогда вообще все как по маслу

даже говнокод нивелируется

Потому теперь приходится переписывать все на мелкие компоненты с 0 на основе люмена. Почему люмена? потому что в случае разрастания функционала сервиса можно накидать вреняемых компонентов или еще больше раздробить без сильной головной боли и одномного количества зависимотей хвостом

Это вы так эту црм написали, с архитектора вашего спрашивайте

Ок. У нас ЦРМ для крупной компании написаная на юии. Ввиду своей архитектуры оно все монолитное и разделению практически не подлежит. Делать из юии что-то невразумительное и модульное - головная боль.

У меня один вопрос. Монолит - говно, микросервисы - круто? Это принимать как факт не принимая во внимание ничего?

Монолит херново в данном случае так как клиент анчал испытывать сильный рост и заказывает невероятное количество новых компонентов системы

некоторые их них не пишутся на пыхе

ЦРМ для крупной (!) конторы на PHP - это круто

или вообще работают в режиме реального времени

Как в YII2 обновить таблицу GRID

так все проблема в тупопост архитектора

$.fn.yiiGridView.update('sorders-grid');

не предусмотрел точки с нагрузкой

так все проблема в тупопост архитектора

архитектора юии?

не подумал как масштабировать приложении

архитектора crm

или ты собрался юии мучать и делать из юии лару или симфу?

или что там

Архитектора который выбирал инструменты под задачу

Архитектор сделал ЦРМ под ТЗ

Масштабирование и юии это 2 разные вещи

и, главное начали переписывать крупную црм не на java или c#, а снова на рнр

Нахрена увеличивать время разработки переходя на другие языки?

Причем вообще тут язык?

Чем пыха плоха то?

кароч найдите нормального архитектора который прочитает ТЗ и поймет бизнес задачу и сделает нормальную архитектруру

тут дело не в yii

Это и было сделать

после окончания разработки по ТЗ клиент написал новые задачи

Масштабирование и юии это 2 разные вещи

Какое масштабирование? Разнесение на несколько разных серверов под балансировку нагрузки? Легко

разделение на более мелкие компоненты

Еще раз - речь о CRM (типа SAP. OEBS) для КРУПНОЙ RJYNJHS&

разделение на более мелкие компоненты

Зачем?

КОНТОРЫ*

с целью балансировки не всей системы,а отдельных компонентов

не все компоненты требуют много мозности

а некоторые какраз имебт высокую нагрузку

это все легко предугадывается на этапе планирования )

Еще раз - речь о CRM (типа SAP. OEBS) для КРУПНОЙ RJYNJHS&

Система позволяет учитывать лидов, заказы, склад и очетность с финансами.

это все легко предугадывается на этапе планирования )

ок. Как ты угадаешь что клиент захочет написать POS модуль для компаний-партнеров который должен работать реал тайм когда тебе говорят в начале что система должна просто вести учет лидов и заказов?

Если тут реально система которая должна работать на 2+ серверах, то изначально писать её надо с расчётом на это. Фреймворк тут не причём. Или ты думаешь что если накидать связанного кода в Симфони/Ларавел, то он одним движением мышки разнесётся на кластер?

Система позволяет учитывать лидов, заказы, склад и очетность с финансами.

и вы решили снова на уии ее периписать? на основе этого негативного опыта отговариваете теперь новичов от неё?

Нет, но количество времени требуемого на разделения лары меньше чем у юии

в 99% у юии придется тупо убирать сам юии

и вы решили снова на уии ее периписать? на основе этого негативного опыта отговариваете теперь новичов от неё?

сжатые сроки и наличие свободных программистов-спецов по юии

причина конечно так-себе, но так получилось уже

сжатые сроки и наличие свободных программистов-спецов по юии

и давай теперь yii вовсю хаять и отговаривать от её изучения

составьте хотябы mind-map по модулям и распишите что они делаеют и примерная нагрузка

это предовтратить 90% факапов в архитетуре

не формальное ТЗ, а для себя - чтобы понять

составьте хотябы mind-map по модулям и распишите что они делаеют и примерная нагрузка

это и было) нам никто ен сказал что будут пиздоватые модули после)

мы когда услышали что они начали думать в сторону реал тайма мы офигели

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

ты будешь все делать мего расширяемое?

тогда точно в симфони превратится с кечей абстракции

у меня примерно такая же задача сейчас

и я не понимаю проблем

на сложных участках будет go

легко ляжет всместо yii

просто я подумал на старте )

у тебя были данные о таких "сложных" модулях в начале?)

у нас нет)

у нас по факту было куча крудов и графиков

Напомню, что все началось с совета, с чего начать учить уии)))))

))

Ок. Я покажу еще один моент почему не стоит)

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

не могут выбрать инструмент по задачу

Ни одна европейская или американская компания не знает о юии

как и программисты оттуда

ну это да

потому компании не хотят иметь дело с юии

лара уже в СНГ набирает обороты

Дык Макаров наш, воронежский

ну был же азиат из сша котоырй создал юии

но отказался почему-то)