Надо ли бросать исключение при приеме ошибочных (невалидных) данных?

Спасибо за помощь

Надо ли бросать исключение при приеме ошибочных (невалидных) данных?

Muhammad: Ну я в контексте роутинга и ответил. Про весь laravel ничего сказать не могу, но api роутинга действительно легче...

Надо ли бросать исключение при приеме ошибочных (невалидных) данных?

Muhammad: Согласен. Laravel легче, но я сделал так как зародилось в голове, да и сделано это ради изучения MVC, так что в будущем наверное будет сложнее, но и опыт ценнее, согласитесь.

Надо ли бросать исключение при приеме ошибочных (невалидных) данных?

Роман: Я решил обезопасить себя. Причины описал в шапке. Спасибо за участие в обсуждении вопроса...

Надо ли бросать исключение при приеме ошибочных (невалидных) данных?

С этим случаем я разобрался, а нужно ли бросать исключения при синтаксических ошибках. Например, синтаксическая ошибка при написания правила роутинга.

//Это верное правило (URL => Контроллер, Действие)
$rules = [['Emergency/:app/:action'] => ['controller' => '\MyEngine\Controllers\:app', 'action' => ':action']];
//Ошибка в плейсхолдере :app, без ":" для роутера он не виден, и 
//в дальнейшем разборе правила он не найдет замещающие данные
$invalidRule = [['Emergency/app/:action'] => ['controller' => '\MyEngine\Controllers\:app', 'action' => ':action']];

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

Простите. Я не умею точно выражать мысли, но вы ответили на мой вопрос.

Чем отличаются ОП коды от Байт кодов php?

Я понял, спасибо

Как правильно распарсить строку?

Иван Корюков: Понял. Спасибо

Как правильно распарсить строку?

Появилась проблема. Я смог реализовать ваш алгоритм, но, допустим строка /emergency/module/app/action вполне проходит проверку /\/emergency\/([a-zA-Z]+)\/([a-zA-Z]+)/
Пробовал Объявлять начало(^) и конец строки($). В таком случае проверка вовсе выдает 0 совпадений

Как правильно распарсить строку?

Спасибо.

Где грань между созданием экземпляра объекта (new Class()) и использованием оператора разрешения области видимости (::)?

Хорошо. спасибо.

Где грань между созданием экземпляра объекта (new Class()) и использованием оператора разрешения области видимости (::)?

Алексей Уколов: Спасибо за дополненный ответ!

Где грань между созданием экземпляра объекта (new Class()) и использованием оператора разрешения области видимости (::)?

Алексей Уколов: Долго доходило. Но я вас понял. Спасибо за ответ, вопрос решен..

Где грань между созданием экземпляра объекта (new Class()) и использованием оператора разрешения области видимости (::)?

Уже ближе. А на примере приведенного мной класса Form можете объяснить. Можно ли его использовать как контейнер со статическими методами?

Где грань между созданием экземпляра объекта (new Class()) и использованием оператора разрешения области видимости (::)?

Если я вас правильно понял: Class::constrict1(), Class::construct2() использовать в зависимости от ситуации?
Ситуация: Допустим, у меня есть класс helpFuncs. Который используется как контейнер функций, которые могут использоваться повсеместно, допустим helpFuncs::addPrefixes(array $data, $prefix), или helpFuncs::translit(string $data); Как в таком случае мне поступить? Не вижу смысла создавать экземпляр через new.

Как правильно валидировать запросы Http запросы php?

Алексей Скобкин: Вы ответили на все мои вопросы. Спасибо

Как правильно валидировать запросы Http запросы php?

Я не умею выражать мысли. Проще говоря так. Я хочу знать, где лучше проводить валидацию входящих данных, чтобы защититься от XSS?
Допустим отправляется запрос example.com/news?act=edit&id=1
В контроллере news я получаю данные запроса через класс client (не напрямую через $_GET). Client класс при инициализации создает контейнер данных, которые пришли от клиента.

Вот мне интересно, фильтровать данные непосредственно в Client class (в случае получения данных, непрошедших валидацию выкидывает исключение). Или же освободить класс от ответственности за валидацию данных и проверять их вручную в коде модели?

Чем оправдано использование QueryBuilder и ActiveRecord в одном проекте?

> И в сумме называется это ORM
Наконец-то я догнал что из себя оно представляет. Я потерялся в лесу среди AR, QUERYBUILDER, DAO, DOCTRINE и в частности ORM... Вы открыли мне глаза. Спасибо

Чем оправдано использование QueryBuilder и ActiveRecord в одном проекте?

Оправдано ли использование Кверибилдера в случаях, когда он используется крайне редко?

Чем оправдано использование QueryBuilder и ActiveRecord в одном проекте?

Мне интересна следующая ситуация:

Есть код на AR вида findBySql($sql). $sql соответственно имеет в себе саму строку запроса(допустим с UNION). Так же допустим что такие запросы - экзотика и используются редко, но в разных кусках проекта(придется искать). При переезде например с Mysql на Oracle или MSSQL, синтаксис запроса придется менять, однако не так просто найти. Сможет ли Квери билдер недопустить этого. Как я понимаю, в можно просто в его методах немного подправить синтаксис и не придется мучаться, в поисках нужных кусков кода по всему проекту?