cgi

Ох...

Model View Controller. Да ну его, ему уже 45 лет (придумали в 79-ом году). Давайте лучше про Model View Adapter погокорим. это то что все используют в популярных фреймворках последние лет так 10 так точно.



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

View - это не только HTML, но и вообще представление в целом, а так же логика его формирования. Шаблонизаторы, фильтры, различные функции/объекты помогаютщие нам сформировать view (например форматирование дат, сериализаторы и т.д.) В подавляющем большинстве случаев "представление" наших данных - это HTTP запросы и HTTP ответы. HTML - э то лишь часть HTTP ответа.

Model - Это целый слой, который может быть представлен в виде кучи отдельных объектиков, структур и т.д. Его задача - делать дела и хранить/менять состояние системы. Тут легко запутаться потому что термин "модель" много чего значит. Воспринимайте его как "слой логики" а не конкретные объекты. И да - база данных и прочая чушь - это детали реализации этого слоя. "не важные штуки" словом. Туда же и ActiveRecord, ORM-ки всякие. Это деталь реализации и все остальные чуваки (view и controller) о них знать ничего не должны (хотя иногда могут в целях упрощения).

Controller или адаптер. Это опять же не обязательно один объект. это может быть цепочка адаптеров (еще называют фронт-контроллером, middlewares и т.д.). Его задача весьма простая. Получаем представление данных на входе (HTTP запрос), определяем что надо делать, и просим модель что-то сделать (ни в коем случае не меняем ничего самостоятельно в контроллере, он только просит). Потом мы можем попросить модель вернуть нужный нам кусок состояния, и попросить View сформировать представление (HTTP ответ).

Как-то так. В целом же это я сейчас описал "идеальный мир". Вся суть этого подхода - разделение логики презентационной и логики приложения. Зачем это надо? что бы было проще жить! Обычно UI приложения или способы взаимодействия с ним меняются почаще логики или как минимум в разные моменты времени. Адаптеры в этом случае служат промежуточным слоем, они ничего сами не делают, это "переводчики". Они просто переводят то, что сказано в запросе в язык понятный приложению и обратно.

Но на начальной стадии можно слегка нарушать эти правила, делать толстые контроллеры и т.д. В этом случае бизнес логика будет потихоньку "вытекать" из модели. Это не хорошо, и на хоть сколько нибудь больших проектах может привести к проблемам. Потому важно находить баланс.

FROM clause
WHERE clause
SELECT clause
GROUP BY clause
HAVING clause
ORDER BY clause

Да, нужно, в большинстве случаев. Можно создать класс ValidationException, который принимает в конструкторе массив сообщений с ошибками и унаследовать его от класса Exception:

class ValidationException extends Exception
{
    /**
     * Validation error messages.
     * 
     * @var array
     */
    protected $errors = [];

    /**
     * Constructor.
     * 
     * @param array $errors
     */
    public function __construct($errors)
    {
        $this -> errors = $errors;
    }

    /* геттер для свойства $errors */
}

Нужно ли бросать исключение, в случаях, когда данные не прошли валидацию?

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

Или достаточно просто занести код и сообщение ошибки в массив errors и при выводе работать с ним?

Не стоит, возвращайте сразу ErrorResponse.

Полезна ли информация с Исключений при валидации во время дебагга?

Да, так вы получаете stacktrace, помимо сообщения об ошибке.

Работа с ошибочными данными может вызвать ошибку непосредственно при их обработке.

Лучше не используйте ошибки, с ними не удобно работать, вместо этого исключения.

Вот вам пример, Assert::assert - это штука из либы ko-ko-ko/assert

public function loginAction(Request $request) : Response
{
    try {
        $userName = $request->request->get('userName');
        $password = $request->request->get('password');

        Assert::assert($userName, 'userName')->match('/^[\a-z\d]{3,32}$/i');
        Assert::assert($password, 'password')->lengthBetween(6, 32);
    } catch (\Throwable $exception) {
        return new Response($exception->getMessage(), Response::HTTP_BAD_REQUEST);
    }

    try {
        // Your business logic here
        
        return Response();
    } catch (\Throwable $exception) {
        $this->get('logger')->error($exception->getMessage(), ['exception' => $exception]);
        return new Response('Could not login', Response::HTTP_INTERNAL_SERVER_ERROR);
    }
}

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

Источник: https://habrahabr.ru/post/282764/

jb_tmp, это, очевидно, JetBrains temp-файл:) А проблема в том, что у вас вотчер пытается смотреть за всеми файлами:
watch('src/ts/**/**', function(event, cb) {
Исправьте путь на 'src/ts/**/*.ts', должно помочь.

Решил использовать коды ИАТА:
betravel.ru/iata-country-list.php