Снова немного DDD, моё решение пары проблем

[Andreika]

В случае с инкрементом и билдером получается, что у нас уже два элемента знают как создать/получить и сохранить сущность в хранилище (базе) - билдер и репа, что тоже как-то странно.

 

[AnrDaemon]

Нет, как сохранить, знает только репо.

 

[Andreika]

ну вот такой код из статьи

namespace Infrastructure;

final class MySqlClientBuilder implements ClientBuilder
{
    private $connection;

    public function __construct(Connection $connection);

    public function buildClient()
    {
        $this->connection
            ->insert('clients_table', [
                $this->name,
                $this->corporateForm,
                $this->generalManager->getId(),
                $this->address
            ]);
       
        $id = $this->connection->lastInsertId();
       
        return new Client(
            $id,
            $this->name,
            $this->corporateForm,
            $this->generalManager,
            $this->address
        );
    }
}

может с какой-то точки зрения и не сохраняет, но после него запись появляется в базе. А если не вызывая $repository->save($entity); мы уже можем получить её из $repository->get(), то почему это не сохранение?
ну а если это сохранение вне репы, то это
сущность в непонятном состоянии (все ли мы сохраняем в buildClient или только нужные для получение id поля?), если до $repository->save() мы не дошли (упали по дороге)
размазанный по проекту код работы с хранилищем/базой - поправили в репе новое обязательное поле, перестали создаваться id
управление кэшем (если оно реализовано в репе) или дублируется или в билдере есть еще и зависимость от репы для управления кешем или...
В общем, схема и все её преимущества пока не очень понятны (

 

[AnrDaemon]

Дело в том, что это ПРИМЕР.
Нормально ты бы передал в конструктор не connection а repository.

 

[Andreika]

ну разве слово Repository сложнее написать, чем Connection? Почему тогда класс называется MySqlClientBuilder, если MySQL там внутрях или запись в файл билдер уже не волнует - у него не Connection, a Repository. Ну и собственно смысл этого класса потерялся, если логика ушла в репу.

 

[Вурдалак]

Дело в том, что это ПРИМЕР.
Нормально ты бы передал в конструктор не connection а repository.

Не нужно додумывать, здесь происходит INSERT и репозиторий не используется. А не используется он по той причине, что @Sufir поленился решить проблему по-нормальному с отказом от AUTO_INCREMENT, пытаясь притянуть за уши билдер, который якобы решает проблему большого числа аргументов (которой нет), а нас самом деле решает проблему прокидывания $id в конструктор сущности.

 

[Sufir]

А не используется он по той причине, что @Sufir поленился решить проблему по-нормальному с отказом от AUTO_INCREMENT

Не нужно додумывать, подозреваю что решить проблему с отказом от AUTO_INCREMENT было бы не только правильнее и красивее но ещё и проще, если бы такой отказ был возможен. Если есть хоть какие-то альтернативные возможности, разумеется стоит рассмотреть их в первую очередь. Да, основная цель - идентификатор, билдинг бонусом.

 

[Вурдалак]

если бы такой отказ был возможен

Почему ты не можешь отказаться?

А что тебе мешает перевести существующую таблицу на sequence? Берешь, увеличиваешь на продакшен таблице AUTO_INCREMENT на 100500, создаешь sequence с id, который был максимальный на момент увеличения. Тут главное, чтобы на время тестов твой sequence не «догнал» AUTO_INCREMENT с прода. Потом после деплоя увеличиваешь sequence как MAX(id) + 100500.