Да, важнейшее слово в программировании, в бизнесе и всём-всём-всём в нашей жизни - это "целесообразность".rugabarbo писал(а):Дима, всё верно, но любая сложность должна быть оправдана.
А вот здесь с трендом не соглашусь. Их как было мало, так и остаётсяrugabarbo писал(а):Всё меньше людей, способных рационально взвесить, что нужно использовать, а что нет.
Начни от противного. Стоит ли использовать модель в качестве хелпера? Нет такой здравой практики в модели создавать статические методы для получения какой-то коллекции объектов. Модель Post - об объектном отражении строки из базы данных, а не о хелпере для запросов в БД. И основываясь на этом тезисе и нужно действовать.rugabarbo писал(а):Дима, всё верно, но любая сложность должна быть оправдана. Давай посмотрим, что говорит про тот же самый сервисный слой Мартин Фаулер:
Т.о. введение сервиса оправдано, если его действительно удаётся повторно использовать (задействовать один и тот же Service Layer в контроллерах сайта и в контроллерах API, например). Но вводить доп.слой просто для следования трендам - избыточно, нерационально.The easier question to answer is probably when not to use it. You probably don't need a Service Layer if your application's business logic will only have one kind of client - say, a user interface - and it's use case responses don't involve multiple transactional resources. [...]
But as soon as you envision a second kind of client, or a second transactional resource in use case responses, it pays to design in a Service Layer from the beginning.
То же самое про остальные перечисленные тобой вещи. Даже авто-тесты писать с самого старта проекта слегка избыточно. Есть критерии, которые позволяют оценить целесообразность написания авто-тестов под конкретный проект.
Есть примеры, когда очень крупные Highload-проекты годами жили без QA-отделов. То есть вообще ничего не тестировали. Посмотрите историю технического развития Badoo, например. У них очень долго не было тестирования и отдела качества.
Увы, программирование всё больше становится похожим на моду: "Ребята, что там в тренде? Сервисный слой, авто-тесты, события, NoSQL-решения, ангулярка? Хм... А дай-ка я тоже всё это запихаю в свою разработку! Раз уж вы говорите, что это лучшие практики, то они явно не помешают."Всё меньше людей, способных рационально взвесить, что нужно использовать, а что нет.
Согласен по всем пунктам. В качестве хелпера использовать модель/AR не стоит. Также я признаю, что встречал проекты, где так делали и приходилось делать также, дабы не вступать в холивар со всей командой разработкиzelenin писал(а):Начни от противного. Стоит ли использовать модель в качестве хелпера? Нет такой здравой практики в модели создавать статические методы для получения какой-то коллекции объектов. Модель Post - об объектном отражении строки из базы данных, а не о хелпере для запросов в БД. И основываясь на этом тезисе и нужно действовать.
Нет ни одного рационального довода создавать статические методы для выборок из базы в модели.
Вот есть у меня сайт без API, без навороченных биллингов и B2B-панелей. Есть только сайт и админка. Код выборок живёт прямо в контроллерах (используется AR + ARQuery). Я бы не сказал, что код контроллеров админки и сайта дублируется (в силу специфики обработки запросов в админке).зачем не выносить?rugabarbo писал(а):Согласен по всем пунктам. В качестве хелпера использовать модель/AR не стоит. Также я признаю, что встречал проекты, где так делали и приходилось делать также, дабы не вступать в холивар со всей командой разработкиzelenin писал(а):Начни от противного. Стоит ли использовать модель в качестве хелпера? Нет такой здравой практики в модели создавать статические методы для получения какой-то коллекции объектов. Модель Post - об объектном отражении строки из базы данных, а не о хелпере для запросов в БД. И основываясь на этом тезисе и нужно действовать.
Нет ни одного рационального довода создавать статические методы для выборок из базы в модели.
Но дополнительно я хочу задать один вопрос... А зачем вообще для выборок делать хелпер?
Зачем я буду на таком проекте оборачивать запросы во что-то дополнительное? Нет у меня дублирования кода в контроллерах (или же оно минимальное). Зачем доп.классы или сервисный слой? Зачем выносить?
как эта фраза сочетается с ниже написанным резюме всей ветки:rugabarbo писал(а):категоричность и перфекционизм часто блокируют нас на пути к дальнейшему развитию (:
Тогда стоит уточнить что это модель AR, а не просто модель.zelenin писал(а):Модель Post - об объектном отражении строки из базы данных, а не о хелпере для запросов в БД.
Я поддерживаю это мнение и считаю что надо делать в рамках него, а не его пытаться загнать в свои рамки.xoma писал(а):Фреймворк позволяет быстро стартануть новичкам и писать более или менее качественный код.
Так в предложениях @zelenin нет никаких рамок. Он описывает довольно популярные и известные подходы.SiZE писал(а):Я поддерживаю это мнение и считаю что надо делать в рамках него, а не его пытаться загнать в свои рамки.xoma писал(а):Фреймворк позволяет быстро стартануть новичкам и писать более или менее качественный код.
Почему ты решил, что эта фраза связана с веткой?zelenin писал(а):как эта фраза сочетается с ниже написанным резюме всей ветки:rugabarbo писал(а):категоричность и перфекционизм часто блокируют нас на пути к дальнейшему развитию (:
...
Да ладно? http://www.yiiframework.com/doc-2.0/gui ... ng-widgetsTrampampam писал(а):к слову, да. Найти вменяемый мануал для новичков нереально. Например: нашел объяснение того, что что-то нужно сделать в виджете и вывести это что-то во вью этого же виджета. ОК, это есть и в гайде.
А что дальше-то?! Как мне это все вывести теперь на самих страницах сайта?! Тишина в мануалах звенящая. ))
Код: Выделить всё
/* viewFileWhatNeedsAWidget.php */
use app\widgets\MyCoolWidget;
echo MyCoolWidget::widget(["config"=>"for", "my"=>"cool", "widget"=>"finish"]);
Не нагнетайте конспирологиюTrampampam писал(а):Может потому и появляютя распухшие модели, контроллеры и незнание классов, что все руководствуются принципов "работает и ладно", а не принципами масштабируемости проекта и снижения прочих издержек, ибо просто нигде не описано, как это делается, особенно, если ты первый раз впялился в пхп - фреймворк вообще.
Всё давно написано, переписано, переведено. И про базы данных, и про архитектуру, и про масштабируемость. Проблема лишь в человеческой лени, ибо никто не читает.ХеллоВиджет работает. Это делал. А вот с примерами, что используют БД туговато. Один хелловиджет всюду.mkramer писал(а):Да ладно? http://www.yiiframework.com/doc-2.0/gui ... ng-widgetsTrampampam писал(а):к слову, да. Найти вменяемый мануал для новичков нереально. Например: нашел объяснение того, что что-то нужно сделать в виджете и вывести это что-то во вью этого же виджета. ОК, это есть и в гайде.
А что дальше-то?! Как мне это все вывести теперь на самих страницах сайта?! Тишина в мануалах звенящая. ))
Видите, людям не до паттерна. Люди не видят в доке, как вызвать созданный ими виджет во вьюхеКод: Выделить всё
/* viewFileWhatNeedsAWidget.php */ use app\widgets\MyCoolWidget; echo MyCoolWidget::widget(["config"=>"for", "my"=>"cool", "widget"=>"finish"]);
Не лукавьте. Прочитать одно, понять другое. Как автор блога, вы прекрасно понимаете, что стиль изложения может быть простым и/или сложным. И в итоге, инфа вроде есть и понять ее могут только подготовленные кодеры, которым это инфа, в принципе, до лампы.ElisDN писал(а):Не нагнетайте конспирологиюTrampampam писал(а):Может потому и появляютя распухшие модели, контроллеры и незнание классов, что все руководствуются принципов "работает и ладно", а не принципами масштабируемости проекта и снижения прочих издержек, ибо просто нигде не описано, как это делается, особенно, если ты первый раз впялился в пхп - фреймворк вообще.
Вы программист, или копипастер? Зачем вам примеры с БД? Вы что, не можете в виджете написать:Trampampam писал(а):А вот с примерами, что используют БД туговато. Один хелловиджет всюду.
Код: Выделить всё
namespace app\components;
use yii\base\Widget;
use yii\helpers\Html;
use app\models\Message;
class HelloWidget extends Widget
{
public function run()
{
$message = Message::findOne(["subject"=>"hello"]);
return $this->render("message", ["message" => $message]);
}
}