#php #mysql #oop #transactions
#php #mysql #ооп #транзакции
Вопрос:
Эта мысль только что пришла мне в голову, и я понятия не имею, сумасшедшая она или нет. Никакие примеры, которые я нашел в Интернете, не настроены таким образом. Я создаю оболочку вокруг MySQLi (или, может быть, PDO), и я только на стадии проектирования. Это для личного проекта, чтобы узнать больше о дизайне OO, поэтому, хотя я ценю мысли об использовании Doctrine или Propel или что-то в этом роде, нет, спасибо. Этот вопрос должен помочь мне изучить некоторые лучшие принципы проектирования; Я знаю, что код будет работать, но с точки зрения дизайна, я схожу с ума?
Это будет мой первый опыт работы с транзакциями на PHP с MySQL. Я понимаю основы — используйте оператор try / catch, зафиксируйте в конце, выполните откат, если есть исключение. Но в середине, вот список операторов для выполнения:
(псевдокод)
try
{
$db->startTransaction();
$db->query('...');
$db->query('...');
$db->query('...');
$db->commit();
} catch (Exception $exc)
{
$db->rollback();
}
Что, если query метод добавляет запросы во внутренний массив? Затем commit метод выполняет этот тип try / catch внутренне и выдает другое исключение. Вот так (опять же, псевдокод):
$db = new AwesomeDBWrapper('...');
$db->query('...');
$db->query('...');
try
{
$db->commit();
} catch (AwesomeDBWrapperCommitException $exc)
{
echo $exc;
}
commit Метод может запускать транзакцию, запрос, фиксацию или откат. Это может сработать, но мой вопрос действительно касается дизайна — это слишком много?
В моем псевдокоде есть подводные камни — он не учитывает чтение и запись в базу данных, Поэтому на самом деле должны быть query методы , update , insert , delete , и т. Д.
Имеет ли это какой-либо смысл с точки зрения проектирования OO? Это кажется приятным с точки зрения кодирования — вы можете писать свои операторы вне try / catch в обычном коде, а затем выполнять позже. Это также кажется немного раздражающим в этом отношении…
Комментарии:
1. Очереди не имеют особого смысла. PHP не является потоковым, и вызовы db будут блокироваться до завершения операции с db. Поскольку вам нужно дождаться завершения предыдущей операции, прежде чем вы сможете начать новую, нет смысла иметь очередь.
2. Я не так сильно беспокоюсь о потоковой передаче и блокировке здесь — дело больше в коде и его удобстве использования / возможности повторного использования.
3. Постановка в очередь не имеет особого смысла, когда транзакции зависят последовательно. например, вставьте строку, затем вставьте идентификатор вставки новых строк для генерации следующей последовательности. Вероятно, вы обнаружите, что большинство последовательностей запросов, с которыми вы столкнетесь, относятся к этому типу, и просто заполнять запросы в очередь не имеет особого смысла, даже если это не для потоковых целей.
4. Это имеет больше смысла — я не рассматривал возможность получения идентификатора вставки. Хорошая мысль, спасибо!
Ответ №1:
Имеет ли это смысл с точки зрения проектирования OO? Вроде того. Имеет ли это смысл с точки зрения использования базы данных? Определенно нет.
Как отметил Марк Б в комментарии, база данных в любом случае уже ставит операции в очередь, поскольку они блокируют вызовы *. Они будут происходить в таком порядке. Просто позвольте ему делать свое дело.
*: хотя вы МОЖЕТЕ совершать неблокирующие вызовы, обычно это не так.
Комментарии:
1. Как я ответил Марку, меня не обязательно беспокоит производительность приложения, хотя я, конечно, не собираюсь сильно снижать производительность. Это больше касается самого кода и того, как программист может его использовать. Если это не повлияет на производительность, имеет ли это смысл с точки зрения использования?