Tinyorm - простой как 2 копейки ORM для PHP

[crocodile2u]

Всем привет.

Мой вклад в велосипедостроение: https://github.com/crocodile2u/tinyorm . Велосипед простой, стадия - бета. Почему и зачем? Да просто существующие решения, на мой скромный взгляд, слишком громоздкие. Ну и я реализовал несколько фишек, которые не так часто можно встретить:

- Persistence Drivers - одну и ту же Entity можно сохранять/вставлять/обновлять с помощью разных бэкендов. для меня, например, актуальна возможность работать с Entity как с помощью MySQL, так и с помощью Handlersocket. Напрашивается также Memcache-backend, но пока не реализован.
- TxManager - менеджер транзакций, поддерживающий несколько соединений с БД. Начали транзакцию, работаете с одним, другим, третьим соединением, потом закоммитили - и менеджер закоммитит все. Либо откатит все, если вы скажете rollback().
- Ну а еще мне нравится мой Select ;-) . Класс для построения SQL-запросов. Совместимость с разными СУБД, возможно, не сильно на уровне, проверено пока только на MySQL, но Postgres и Sqlite тоже должны работать.

Если кому понравится - милости прошу, пользуйтесь. Пишите, участвуйте.

 

[grigori]

с возвращением, давно тебя не было

 

[crocodile2u]

с возвращением, давно тебя не было

Да)) Я еще и на DevConf заявку подал))

 

[crocodile2u]

Очередные anemic entities с претензией на persistence ignorance. Потрясающе.

Спасибо за содержательную оценку. Ваш комментарий спорный. Я для себя выработал свод внутренних правил, согласно которым до определенного предела логику домена в Entity держать можно. Не в автогенеренной (чтобы не потерять возможность спокойно перегенерить), а в классе-наследнике. Для меня это работает. Работает на протяжении лет. Уверен, что есть и другие, для которых этот подход точно так же работает. Спасибо.

 

[Вурдалак]

Если вот это просто:

final User extends \library\scaffold\User {
    // ...
}

То это должно быть ещё проще:

final User {
    // ...
}

Кстати,

Напрашивается также Memcache-backend, но пока не реализован.

/** @var Book $book */
$book = Registry::persistenceDriver()->find((int) $_GET["id"], new Book());
// ...
$bookAuthors = $book->getAuthors()->execute()->fetchAll();

А что будет, если мы заменим MySQL-хранилище на другой, как ты говоришь, backend?
А, судя по тому, что нужно менять наследуемый класс и драйвер одновременно, прозрачной замены не предполагается.

Я так подозреваю, что это очередной раз, когда понятие простоты очень относительно.

 

[crocodile2u]

Просто "final User", разумеется, проще. И я рассматривал такое решение. Пришел к выводу, что если уж я пишу все это для таких Entities, которые все же лежат в некоем хранилище - то удобно будет иметь определенный минимальный набор операций, характерный для таких "сохраняемых" объектов - непосредственно в этих самых Entities. Да, это нарушает Single-Responsibilty-Principle. Но это вопрос выбора - множить сущности или нет? В данном случае я предпочел не множить.

Persistence drivers управляют только простейшими операциями: "найти по ID", "сохранить", "обновить", "вставить", "удалить". Сейчас в поставке только 2 драйвера: DbDriver (на основе tinyorm\Db - обертка вокруг PDO) и ZhandlersocketDriver (на основе расширения Zhandlersocket - коннект к InnoDB-таблицам через handlersocket). Если есть MySQL с включенным handlersocket, то в данном приложении ничего не изменится (это код из небольшого примера использования библиотеки). Если, допустим, добавить драйвер, сохраняющий в Memcache - то он будет сохранять в Memcache. Имеет смысл, очевидно, только для пременного хранения.