Класс(-ы) для таблицы наследуется от AR, который в свою очередь наследуется от yii\base\Model
Валидация в виде метода rules() уже присутствует в yii\base\Model, но в виде «заглушки» (возвращается пустой массив). Метод переопределяется в классе-наследнике AR, на основе типов данных самой таблицы.
А уже далее можно еще раз наследоваться (причем неоднократно), для REST модели, для ORM-модели, для модели формы и так далее. А уже в каждом из этих наследников можно переопределять/дополнять правила валидации, правильно составляя массив, возвращаемый методом rules()
При записи в бд каких либо данных от пользователя фильтроваться должно от инъекции.
При выдаче результата из базы должны экранироваться теги.
Это конечно я «грубо», иногда зависит от ситуации, но для первого правила должно быть именно так.
У меня такое было…
Дам совет из личного опыта, при разработке занимайтесь проектированием бд до самого последнего поля и ключика.
Планируйте архитектуру приложения заранее, с возможностью расширения не за счет «костылей», а за счет добавления новых архитектурных модулей или компонентов.
Лишние пару дней проектирования сэкономят пару лней разработки, а впоследствии еще и пару дней на тесты и исправления
Это не борьба с orm, а использование его возможностей.
Автор как раз это и сделал, использовав with. А раз ему и join нужен был — joinWith(). Это и так в документации очень хорошо написано, автор в данном случае показал, как это к грид применить.
Валидация в виде метода rules() уже присутствует в yii\base\Model, но в виде «заглушки» (возвращается пустой массив). Метод переопределяется в классе-наследнике AR, на основе типов данных самой таблицы.
А уже далее можно еще раз наследоваться (причем неоднократно), для REST модели, для ORM-модели, для модели формы и так далее. А уже в каждом из этих наследников можно переопределять/дополнять правила валидации, правильно составляя массив, возвращаемый методом rules()
При выдаче результата из базы должны экранироваться теги.
Это конечно я «грубо», иногда зависит от ситуации, но для первого правила должно быть именно так.
Но соглашусь.
Дам совет из личного опыта, при разработке занимайтесь проектированием бд до самого последнего поля и ключика.
Планируйте архитектуру приложения заранее, с возможностью расширения не за счет «костылей», а за счет добавления новых архитектурных модулей или компонентов.
Лишние пару дней проектирования сэкономят пару лней разработки, а впоследствии еще и пару дней на тесты и исправления
Автор как раз это и сделал, использовав with. А раз ему и join нужен был — joinWith(). Это и так в документации очень хорошо написано, автор в данном случае показал, как это к грид применить.