FanatPHP

Все правильно, никакая проверка здесь не нужна.

Ошибки должен отлавливать обработчик ошибок. Который уже будет сам решать - что показать на экране, а что записать в лог.

Ответ на этот вопрос очень простой.

- Если ты пишешь процедурный код, то в синглтоне нет никакого вреда, а только одна польза.
- Если же ты пишешь объектный код, то синглтон тебе просто не нужен, поскольку в объект при создании всегда можно передать инстанс класса для работы с БД и присвоить переменной класса.

по поводу реализации

1. Как уже сказали выше, какой-то странный метод getInstance(). Если каждый раз вызывать с парасетрами, то какой вообще смысл в синглтоне? Сделай хотя бы два метода, один коннект, а второй гетинстанс.
2. Не очень понятно почему две статические переменные, и какая за что отвечает. почему бы не оставить одну?
3. Если уж делать синглтон, то лучше избавляться от лишней писанины, и обращаться напрямую к методам для работы с БД: `DB::insertId()` будет поудобнее, чем `DB::getInstance()->insertId()`
4. Учитывая неудобство метода PDO::execute(), будет полезным подправить классиков и добавить метод, который будет выполнять запрос с параметрами и вернет стейтмент. Пример можно посмотреть здесь: https://phpdelusions.net/pdo/pdo_wrapper

Всегда, если использовался prepared statement.

Всего-то надо использовать правильную константу ПДО

$lang = $pdo->query("SELECT `key`, `english` FROM language")->fetchAll(PDO::FETCH_KEY_PAIR);
echo $lang['solved'];

Классическое решение:

<?php
$ids=array(1,2,3,7,8,9);
$in  = str_repeat('?,', count($arr) - 1) . '?';
$stmt = $db->prepare('SELECT * FROM table  WHERE id IN($in)');
$stmt->execute($ids);

Не слишком красиво, но зато безопасно.

Перевожу на понятный язык ответ DevMan:

Чтобы получить данный функционал, необходимо, чтобы были соблюдены два условия:

- модуль pdo_mysql должен быть собран на базе mysqlnd. проверяется через phpinfo()
- для запроса используются родные подготовленные выражения, что достигается установкой PDO::ATTR_EMULATE_PREPARES в false

> "велосипед" который будет обновляться самой командой в соответствиями с требованиями проекта?

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

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

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

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

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

> Как обычно поступают команды, когда используется сторонний фреймворк, постоянно обновляют его версию в проекте или остаются на старой версии?

Хотя бы за мажорной версией следовать необходимо.

Был старый-старый хак, думаю, что он работает и сейчас

<input type = hidden name = cbx value = 0>
<input type = checkbox name = cbx value = 1>

Работает, как я понимаю, за счет того, что последующее значение затирает предыдущее.
То есть, запрос выглядит как
..&cbx=0&cbx=1&...
в итоге в скрипте получается что-то вроде идущих подряд

$_GET['cbx'] = 0;
$_GET['cbx'] = 1;

И в итоге остается только один.

Отсюда становится понятно, что важно соблюдать порядок - хидден должен идти всегда первым.