Переход с Yii 1.1 на Yii 2.0

Общие вопросы по использованию второй версии фреймворка. Если не знаете как что-то сделать и это про Yii 2, вам сюда.
TM123
Сообщения: 604
Зарегистрирован: 2011.06.09, 11:18

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение TM123 » 2016.11.24, 00:20

Наверное у нас разное понимание завязки на фреймворк.
Мне не понятно в чем заключается жесткость привязки в использовании конструкций
Yii::app()->db*->createCommand($query)->query*();
от
MyMegaFuncDBQuery($query);

Если для вас сделать простую замену в любом текстовом редакторе Yii::app()->db*->createCommand( на MyMegaFuncDBQuery( и )->query*(); на ); если это сложность и это означает переписывание 95% кода, если простая бездумная замена это серьезная проблема, тогда вы правы, но я лично могу использовать хоть Calc и Excel для генерации SQL запросов и PHP кода - если эти запросы и код однотипен.

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

Описанный подход - это пример использования подходящих средств, да это не так красиво с точки зрения высоты полета программисткой мысли, но о том что надо использовать подходящие средства мы вроде как согласились и не гнаться за "чистотой арийской расы".
Если говорить о стоимости поддержания такого кода, вопрос в том, есть ли в проекте человек принимающий код, не тестировщик тестирующий код, а человек именно читающий код перед приемкой и вникающий в его суть, если такой человек есть и он контролирует что каждый новый программер не начинает ляпать очередные дубликаты функций - проблем нет никаких, если такого человека нет, то использование указанных вами слоев только оттягивает возникновение проблемы, но не решает ее. Прочесть быстро код и вникнуть что он делает это гораздо быстрее чем его написать, поэтому накладные затраты на такого рода приемку примерно 1 минута на 1-2 часа написания кода, т.е. код который человек писал целый день можно прочесть за 5-10 минут, редко когда больше и быстро вникнуть что он там наделал и надублировал ли он уже имеющийся функционал не важно в каком виде - методы, функции или просто написав спагетти-код вместо того чтобы вызвать уже имеющуюся функцию. Зато за такие достаточно не большие накладные расходы получается очень существенный прирост в скорости работы приложения, прирост может составлять десятки тысяч раз и это хороший повод чтобы во все это играть, тем более что контролер кода по факту поддерживает чистоту проекта в коде, что тоже не мало стоит.

andrei.obuhovski
Сообщения: 610
Зарегистрирован: 2015.07.16, 10:50

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение andrei.obuhovski » 2016.11.24, 06:39

TM123 писал(а): проект можно отвязать от фреймворка простой заменой названий одних методов на другие, а что таким образом не может быть произведено, быстро (неделя) пишутся аналогичные по функционалу свои базовые классы, либо берутся классы фреймворка из которых выбрасывается все лишнее, либо переписывается класс хелпер - прослойка переводящая термины бизнес-логики приложения в настройки доступные для фреймворка.
Вот и сделайте так на своем текущем проекте. За неделю перейдете с yii 1.1 на yii 2. :)

А вообще вот хорошее пособие по написанию проекта независимым от фреймворка: https://leanpub.com/cleanphp
Там человек пишет проект на зенде, а потом заменяет зенд на ларавел.

Аватара пользователя
maleks
Сообщения: 1824
Зарегистрирован: 2012.12.26, 12:56

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение maleks » 2016.11.24, 11:58

TM123 писал(а):Наверное у нас разное понимание завязки на фреймворк.
Мне не понятно в чем заключается жесткость привязки в использовании конструкций
Yii::app()->db*->createCommand($query)->query*();
от
MyMegaFuncDBQuery($query);

Если для вас сделать простую замену в любом текстовом редакторе Yii::app()->db*->createCommand( на MyMegaFuncDBQuery( и )->query*(); на ); если это сложность и это означает переписывание 95% кода, если простая бездумная замена это серьезная проблема, тогда вы правы, но я лично могу использовать хоть Calc и Excel для генерации SQL запросов и PHP кода - если эти запросы и код однотипен.

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

Описанный подход - это пример использования подходящих средств
Вы этот подход только сейчас придумали (в целях поддержки спора), или долго к нему шли и уже применяли? Имхо подход ваш выглядит как жесть...
Yii2 universal module sceleton - for basic and advanced templates

TM123
Сообщения: 604
Зарегистрирован: 2011.06.09, 11:18

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение TM123 » 2016.11.24, 19:44

maleks писал(а):Вы этот подход только сейчас придумали (в целях поддержки спора), или долго к нему шли и уже применяли? Имхо подход ваш выглядит как жесть...
Я ни о чем не спорю, я себе как программисту давно все доказал и не нуждаюсь в доказывании ничего никому чтобы повысить свою самооценку. Подход ни раз опробован и проверен, таким образом я переносил ASP JScript проекты на PHP, а это куда как сложнее, чем с PHP на PHP. Я занимался переносом Fortran СМ и ЕС ЭВМ программ на Turbo Pascal посредством самописного транслятора и ничего, все начинало работать без ручных исправлений.

Я обсуждаю эту тему, потому что мне она интересна и интересно мнение других людей, которые говорят что-то аргументированно по делу, а не в молодежном СМС формате - нечего сказать, но очень хочется, плюнул и пошел дальше.

TM123
Сообщения: 604
Зарегистрирован: 2011.06.09, 11:18

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение TM123 » 2016.11.24, 19:47

andrei.obuhovski писал(а): Вот и сделайте так на своем текущем проекте. За неделю перейдете с yii 1.1 на yii 2. :)

А вообще вот хорошее пособие по написанию проекта независимым от фреймворка: https://leanpub.com/cleanphp
Там человек пишет проект на зенде, а потом заменяет зенд на ларавел.
Есть большая разница между тем чтобы отвязать и тем чтобы посадить на другой, отвязать легко, а посадить на другой - для этого надо знать другой фреймворк. Yii 1.1 и Yii 2.0 не принципиально разные фреймворки, но тем не менее задача стоит не пересесть из принципа как самоцель, а достигнуть решения некоторого количества проблем и большая часть из них пересадкой на другой фреймворк не решается, эти проблемы повод попробовать пересесть.

За ссылку спасибо, посмотрю.

TM123
Сообщения: 604
Зарегистрирован: 2011.06.09, 11:18

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение TM123 » 2016.11.24, 19:54

Если кому интересно, сегодня много читал и задумался над тем - а стоит ли вообще переходить, проект на 2-ух фреймворках, пусть и одинаковых, но разных версий достаточно напряженное занятие, т.к. в реальности все слова про легкий переход - это художественный свист. Все афторы с рассказами о легкости перехода забывают сказать что они под словом переход понимают переход от программирования под Yii 1.1 на программирование под Yii 2.0 и тут собственно нет никаких проблем, но перевод проекта - это совсем другая тема, на эту тему нет ровным счетом ничего и все надо писать самому, а при таких условиях возникает вопрос целесообразности перехода, тем более что Yii 1.1.17 заявляется что работает на PHP 7.0, что решает еще минимум лет на 5 вперед проблемы поддержки версий PHP, правда у меня пока он не заработал, ошибок нет, просто виснит в процессе ничего не говоря уходя в бесконечное раздумье, но это мы победим, думаю что проблема в настройках новой версии Nginx.

В общем сейчас серьезно думаю чтобы остаться на Yii 1.1 и просто рядом написать новый визуальный клиентский интерфейс, ну и причесать код вообще под использование новых фенечек самого PHP.

sda
Сообщения: 332
Зарегистрирован: 2013.12.19, 09:29

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение sda » 2016.11.24, 23:28

Можно понемногу рефакторить проект на Yii1 и отделять бизнес-логику приложения от фреймворка. Затем будет довольно реально мигрировать на другой фреймворк без тотального переписывания кода. Начать можно с поиска информации о том, как сделать БЛ незвисимой от фреймворка и в целом от стороннего кода.

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

Самый неудачный вариант, это попытаться организовать работу сайта сразу на Yii1 и Yii2. Работать скорее всего будет довольно криво, если вообще будет.

Аватара пользователя
maleks
Сообщения: 1824
Зарегистрирован: 2012.12.26, 12:56

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение maleks » 2016.11.25, 09:05

TM123 писал(а):Подход ни раз опробован и проверен, ... все начинало работать без ручных исправлений.
Ну во первых у вас не стыкуется.
От Yii1 вы захотели отказываться, чтобы бантики от Yii2 использовать:
TM123 писал(а):Есть мнение, что применение Yii 2 увеличит скорость разработки на 20-30%, при этом позволит легко применять бантики. Yii 1.1 тупо банально практически не поддерживается и скоро будет снят с поддержки вообще, библиотеки для бантиков придется писать самостоятельно, так какой смысл их писать под старый фреймворк.
Но при этом согласно вашего подхода, плюшки использовать нельзя:
TM123 писал(а):Когда я говорю что проект слабо завязан на фреймворк, я говорю о том что проект не использует разного рода модных бестолковых плюшек привязывающих его к средству реализации,
Ну а во вторых, может ваш подход вам чем то раньше в каких то процедурных скриптах и помогал(функция на функцию), но это не подход написания фреймворконезависимого кода.
То что вы используя в редакторе функцию "Заменить текст" будете один кусок кода заменять на другой, код у вас фреймворконезависимым не станет. И до и после замены он будет зависимым от какого то фреймворка.
И сам этот процесс со многими неизвестными, например у вас:
TM123 писал(а):Yii::app()->db*->createCommand( на MyMegaFuncDBQuery(
Ну так Yii::app()->db*->createCommand( должна вернуть объект типа yii\db\Command, где вы его найдете в вашем новом фреймворке?
Так само и от ->query() дальше клиентский код будет ожидать yii\db\DataReader объект.
Так что даже на такой простой базе не видно как " проект можно отвязать от фреймворка простой заменой названий одних методов на другие" (с). А что дальше тогда со всем остальным, построители запросов, события, поведения, ничего не использовать?..
Если планируется такое покоцаное использование фреймворка, то и нет разницы какой из них использовать, спокойно можно на yii1 оставаться.

Ну а если гнаться уже именно за фреймворконезависимой архитектурой, то тут хочется или нет, но придется вам разбираться в ДАО той гекса-какой-то архитектуры и очень много задач смотреть как оно вообще может быть осуществимо на практике.
Yii2 universal module sceleton - for basic and advanced templates

TM123
Сообщения: 604
Зарегистрирован: 2011.06.09, 11:18

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение TM123 » 2016.11.25, 13:47

Если кому интересно, Yii 1.1.17 взлетел и проект тоже на PHP7, надо конечно тестировать, но на первый взгляд основной функционал работает. Опять таки, если кому интересна причина почему сразу не взлетел.
PHP7 при установке не сформировал php.ini, чтобы не развлекаться с настройками сунул от 5.6, а в нем папка для хранения файлов с сессиями .../php5, ее конечно же нет по ожидаемому пути, есть папка php7, после такой подставы подправил все пути и случилось счастье. В общем как-то сразу не осознал что все папки имеют в названии номер главной версии php.

Аватара пользователя
maleks
Сообщения: 1824
Зарегистрирован: 2012.12.26, 12:56

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение maleks » 2016.11.25, 14:21

TM123 писал(а):Если кому интересно, Yii 1.1.17 взлетел и проект тоже на PHP7, надо конечно тестировать,
Должно быть нормально, вон ЮПИ нормально себя на PHP7 чувствует, думаю там потестили уже пользователи.
Yii2 universal module sceleton - for basic and advanced templates

TM123
Сообщения: 604
Зарегистрирован: 2011.06.09, 11:18

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение TM123 » 2016.11.25, 14:30

maleks писал(а): Ну во первых у вас не стыкуется.
От Yii1 вы захотели отказываться, чтобы бантики от Yii2 использовать:
Читайте лучше, речь шла не о бантиках PHP или Yii, а о пользовательских, чтобы окошки кульно чинно возникали, чтобы валидация была не явная и т.д., все это делается и на Yii 1.1, почему речь зашла о Yii 2.0 - читайте выше.
maleks писал(а):Ну а во вторых, может ваш подход вам чем то раньше в каких то процедурных скриптах и помогал(функция на функцию), но это не подход написания фреймворконезависимого кода.
То что вы используя в редакторе функцию "Заменить текст" будете один кусок кода заменять на другой, код у вас фреймворконезависимым не станет. И до и после замены он будет зависимым от какого то фреймворка.
Скажите, а чем отличается вызов метода класса от вызова функции, класс - это всего лишь обертка объединяющая воедино данные и методы работы с ними, по сути класс - это более низкоуровневое пространство имен по сравнению с namespace, а всякого рода полиморфизмы, наследования и т.д. - это плюшки организации данного рода пространств имен и не более, да они удобные, много чего позволяют сделать легко, но в своей основе это пространство имен процедурного подхода. Если думать на уровне фундаментальной теории программирования, а не замарачиваться на модные названия различных методов, подходов и концепция программирования, если перейти на более высокий уровень абстракции, то проблема становится простой. Надо разделять собственно саму чистую теорию программирования и различные методы, подходы и концепции которые призваны решить прикладные задачи как бизнесовые, так и самих программистов. Возможно мне это понятно, потому что написал несколько интерпретаторов самопальных языков, но это осталось в прошлом, как только появились нормальные реализации функции eval, но тем не менее самогенерящийся код на PHP и SQL использую постоянно.

Собственно есть правила и синтаксис языка, если вы написали класс на php почему он будет работать на одном фреймворке и не будут работать на другом, если оба фреймворка работают на одном языке, а под работать подразумеваем бизнес логику, вы как вызывали методы и свойств с помощью конструкции -> так вы и будите их вызывать, а частный пример запросов к базе, который я привел в качестве примера, ну так там простая замена решает проблему привязки к фреймворку;
maleks писал(а):А что дальше тогда со всем остальным, построители запросов, события, поведения, ничего не использовать?..
Если планируется такое покоцаное использование фреймворка, то и нет разницы какой из них использовать, спокойно можно на yii1 оставаться.

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

select * from tbl1 t1
inner join tbl2 t2 on t2.id=t1.id
where t1._id='XYZ'
order by t1.name
limit 10

т.е. написать 1 строку, писать минимум 6 вызовов построителя запросов, которые тратят бестолку ресурсы на сборку простой строки (если вы знаете что происходит при вызове метода с точки зрения процессора, то ужаснетесь сколько ресурсов тратится в пустую), вы ведь не собираете сообщение об ошибки из отдельных слов примерно таким образом

$err=new MessageError();
$err->add('Это')->add('мега')->add('сообщение')->add('об')->add('ошибке');
echo $err->getMessage();

вы почему то пишите вот так

echo 'Это мега сообщение об ошибке';

Если вы сейчас захотите сказать про мультиязычные сообщения/приложения, то это не из той область, суть примера в другом - надо уметь во время остановиться в нормализации и декомпозиции.

На мой взгляд построители запросов возникли как интересная умственная задача с важным применением - позволить массе китайких и мексиканских недопрогаммистов 90-ых начала 2000-ых, работающих в силиконовой долине и подобных местах писать более сложные проекты, средство компенсировало слабые знания в предмете, а теперь это добро пихают повсюду как стандарт и хороший тон. Все это напоминает Lotus Notes Domino, написали Lotus Notes хорошая документ-ориентированная база данных, написали пример использования в виде почтаря, почтарей тогда было мало и вот некоторое количество сисадминов поставило этот почтарь как временное решение частоной проблемы, потом какой-то продаван решил что да это же можно продавать и пошло поехало, Lotus Notes Domino наше все для крупняков и дефакто стандарт почтовых систем - эта ересь существовала лет 15, построитель запросов из той же области, правда она не умрет так быстро. У меня полно запросов на 2-3 и более экранов и мне проще написать запрос руками, чем растянуть на 10 экранов вызовы построителя запросов, потом носиться по коду в поисках где и что я сделал не так листая эти 10 страниц, если он вообще построитель сможет построить такой запрос, раньше ни один более менее сложный запрос построить было невозможно, сейчас не знаю, не слежу. Вот и получается что для простых запросов нет смысла использовать, а для сложных либо невозможно, либо затруднительно, зачем тогда все это добро.

P.S. Использование построителя конечно удобно если надо поменять сортировку или количество строк, но эта проблема решается менее накладными со всех точек зрения методами, типа написать запрос без этих 2-ух команд и далее по необходимости добавлять изменения.

Аватара пользователя
maleks
Сообщения: 1824
Зарегистрирован: 2012.12.26, 12:56

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение maleks » 2016.11.25, 14:54

TM123 писал(а): У меня полно запросов на 2-3 и более экранов и мне проще написать запрос руками
Вот эти ваши запросы, их синтаксис, только под какую то одну конкретную БД, да?
Yii2 universal module sceleton - for basic and advanced templates

Аватара пользователя
ElisDN
Сообщения: 5451
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение ElisDN » 2016.11.25, 15:25

TM123 писал(а):...а всякого рода полиморфизмы, наследования и т.д. - это плюшки организации данного рода пространств имен и не более, да они удобные, много чего позволяют сделать легко, но в своей основе это пространство имен процедурного подхода.
Всюду процедурный подход. Понятно. Просто мы думали, что у Вас там есть ООП. А нет - так нет.
TM123 писал(а):Не подумайте что я хочу вас или кого-то обидеть, но считаю что построители запросов - это для лохов не знающих SQL.
Построители или голый SQL - это реализация, к какой-либо архитектурой связи практически не имеющая.

TM123
Сообщения: 604
Зарегистрирован: 2011.06.09, 11:18

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение TM123 » 2016.11.25, 15:54

maleks писал(а):Вот эти ваши запросы, их синтаксис, только под какую то одну конкретную БД, да?
Обычно да, потому что если писать на ANSI SQL, то многие задачи не могут быть выполнены в принципе, потому что каждая команда разработчиков SQL серверов прикладные функции пишут кто во что горазд и по сути это языки с SQL подобным синтаксисом, точно так же как PHP с C подобным синтаксисом.

Мой проект БД зависимый, потому что значительная часть функционала массовых обработок данных вынесена в серверные хранимки и тут никаких вариантов нет, потому что считаю что более менее сложный и нагруженный проект должен по максимуму отдавать обработку данных на сервер базы данных, данные должны по сути обрабатываться там где они возникают перед записью и далее вместе своего хранения, а потребителю должны прилетать сухие выжимки.

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

Запрос типа

select * from tbl1 - это запрос чистой воды ANSI SQL и он отработается на всех серверах и ровно тоже самое построит вам построитель. В чем вам может помочь построитель запросов, правильно экранировать, ставить ` или " - это да, но возвращаясь к предыдущим постам - эта проблема решается простой заменой, т.е. пока вы пишите на ANSI SQL, собственно что вам построит построитель - все прекрасно, но вспоминаем что в ANSI SQL мало что есть, переходя к конкретике вот вам пример реальных запросов имеющих прикладное значение

Для MySQL

select substring('Привет мир', 8, 3) from tbl1

Для Postgres

select substr('Привет мир', 8, 3) from tbl1

На сколько я понимаю, ни один построитель запросов не решит данную проблему, которая вообще смешна, но для ее решения от разработчика построителя требуется хорошее знание всех баз для которых он строит запросы, потому что некоторые манипуляции могут проводится посредством последовательного вызова нескольких встроенных функций, а то что я тут приве очень близкие по названию функции делающие одно и тоже. Ну и что толку о построителя? что он вам сваяет ANSI SQL запрос который одинаково отработается на всех SQL базах поддерживающих соот. версию ANSI SQL, но вы точно так же можете это написать руками, а что дальше? PHP Best Practics?, загрузить все на сервер приложения обработать с помощью foreach? формально можно, но этот метод медленее одного SQL запроса иногда в десятки тысяч раз. Если база и проект малы, а железо по сравнению с ними бесконечно мощное, тогда можно так поступать, но если ресурсы ограничены, а база велика, то это реальная проблема, поэтому я спокойно отношусь к тому что проект садится на какую-то базу данных, на мой взгляд, если нет на средний проект миллионов баксов на железо, это неизбежно.

Если какой-то построитель решает описанные выше проблемы, дайте ссылку, почитаю, интересно.

Формально, описанную выше проблему можно решить посредством определения набора наиболее востребованного набора функций в SQL, а потом составить таблицу соответствия конвертации вызовов под каждую базу, наверное такое когда-то будет сделано, но это будут только очень простые функции, потому что как только вы вдаетесь в реализацию сложных плюшек доступных на одной базе и недоступных на другой, собственно определяющих наш выбор то какая база будет у проекта, все это становится на столько сложно, что становится сопоставимым с разработкой собственного сервера базы данных. Реализуйте массивы и классы на базе которая ни того не поддерживает, задача еще та по сложности, собственно запихнуть в поле типа text serialize не проблема, проблема обеспечить возможность работы с этим serialize и при этом остаться в интервале приемлемых скоростей работы.

TM123
Сообщения: 604
Зарегистрирован: 2011.06.09, 11:18

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение TM123 » 2016.11.25, 16:11

ElisDN писал(а):Всюду процедурный подход. Понятно. Просто мы думали, что у Вас там есть ООП. А нет - так нет.
Это тут причем? я вам говорю об основах, а вы продолжаете летать по верхам не в силах подняться над суетой модных определений и концепций. Вообще хотелось бы посмотреть на реализацию проекта, который работает на ОО фреймворке, а сам весь или в значительной своей части состоит из процедурного подхода. Нет ну конечно можно и так, но интерес вызывает как в таком проекте решили бы массу проблем, так чисто для общего развития, может что-то использовать удалось бы в своей практике, ведь для решения любой задачи надо использовать подходящие средства и методики, а не из принципа создавать объект CInt::create(5) чтобы передать в метод фреймвора число, вместо того чтобы передать 5 как параметр, как это делают в onPHP.

sda
Сообщения: 332
Зарегистрирован: 2013.12.19, 09:29

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение sda » 2016.11.25, 18:50

более менее сложный и нагруженный проект должен по максимуму отдавать обработку данных на сервер базы данных
потребителю должны прилетать сухие выжимки
Как только возникнет необходимость шардить базу на 2+ сервера, то ваша концепция по выносу логики в базу рухнет. Придется переписывать абсолютно всё приложение.

Аватара пользователя
ElisDN
Сообщения: 5451
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение ElisDN » 2016.11.25, 18:57

TM123 писал(а):Вообще хотелось бы посмотреть на реализацию проекта, который работает на ОО фреймворке, а сам весь или в значительной своей части состоит из процедурного подхода.
Практическое большинство проектов на Yii фреймворке написаны процедурным лапшекодом с присваиванием полей голым ActiveRecord-структурам и завалены статическими методами с синглтонами по самые помидоры. Заполнить поля и вызвать $model->save() - это не ООП.

Restlin
Сообщения: 139
Зарегистрирован: 2011.09.09, 18:12

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение Restlin » 2016.11.26, 14:28

Долго думал как высказать свое мнение о проектировании системы ТС-ом, но лучше я спрошу о наболевшем:
TM123 скажите пожалуйста как вам удается сопровождать бизнес-логику на стороне sql сервера?
Как вы контролируете изменения в процедурах и функциях, их зависимости между собой и от структуры БД?
Как контролируете изменениями функций и процедур новичками?
По работе мне приходится сталкиваться с таким корпоративным наследием (90% логики на стороне БД), системы существуют более 10-15 лет - огромная кодовая база - пытаться сопровождать такое полный ад.
На их фоне небольшие модульные задачки на том же yii1/yii2, взаимодействие которых происходит только через API выглядят пока что намного эффективнее.(Справедливости ради 10-15 лет еще естественно не прошло)

TM123
Сообщения: 604
Зарегистрирован: 2011.06.09, 11:18

Re: Переход с Yii 1.1 на Yii 2.0

Сообщение TM123 » 2016.11.28, 11:06

sda писал(а):Как только возникнет необходимость шардить базу на 2+ сервера, то ваша концепция по выносу логики в базу рухнет. Придется переписывать абсолютно всё приложение.
Есть такая проблема, но в моем случае ее нет и не возникнет.

Ответить