ребята, такой вопрос. Есть сущность Database, которая представляет базу данных, которую можно сдампить и восстановить из дампа, причём в полях сохраняется информация вроде даты последнего восстановления после dump или import. Хочется юзать что-то вроде $db->import($pathToDump) и $db->dump($pathToDump). Нужно ли в таком случае передавать в методы объект, который действительно будет делать работу с базой и файлами? Или создавать отдельный объект, который будет вызывать эти методы и делать работу с файлами?

то есть типа $db->import($path, $dbManager)

или $dbManager->import($database, $path)

или что-то типа $dbAssistantFactory->create($database)->dump($path);

или что-то типа $dbAssistantFactory->create($database)->dump($path);

сущность она потому что тебе надо лог хранить что когда делал?

Лог, размер базы и прочее

что будет если мы начали лить дамп и что-то пошло не так? мы должны как-то это отображать в логах?

ох, это важно?)

ну так)

а если рассмотреть оба варианта?

ну в любом случае я бы сервис аргументом передал

дело не конкретно в этом примере, часто я сталкиваюсь с мыслью, что неплохо было бы в сущность добавить зависимость

но вроде как нельзя такое делать

ну тебе никто не мешает это делать)

а ты делаешь так?

ну вот есть DatabaseManager с методами drop(database) create(database) dump(database) import(database)

у тебя есть 2 варианта: - double dispatch, то есть через аргументы метода - "заинджектить" через конструктор + postLoad доктрины - но что бы то было валидно у тебя ВСЕ методы твоей сущности должны пользоваться этой зависимостью.

и в каждом методе по одному аргументу, принимающего database на вход

почему-то хочется переместить логику в сам database

вроде как дальше от процедурного подхода

у тебя есть 2 варианта: - double dispatch, то есть через аргументы метода - "заинджектить" через конструктор + postLoad доктрины - но что бы то было валидно у тебя ВСЕ методы твоей сущности должны пользоваться этой зависимостью.

а как это через конструктор заинжектить, я не понял

вроде как дальше от процедурного подхода

но это не точно

а как это через конструктор заинжектить, я не понял

ну берешь и засовываешь зависимость в конструктор сущности, а потом через postLoad ее обратно засовываешь когда доктрина тебе ее достает

что, $entity->__construct(DbMan $m) вызывать, или reflection?

рефлекшн, я так понял

ну да, конструктор то вызвался уже один раз и больше низя

но я так ни разу не делал и таки задач как у тебя у меня небыло... я не очень уверен что Database это сущность

да я чет такого не видел, чтобы люди делали

да я чет такого не видел, чтобы люди делали

ну у меня простая аналогия

вот допустим используются у меня на проекте Doctrine и Prooph

и я хочу подружить сущность пруфовскую с доктриновской

они ж обе просто 2 объекта

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

тут к слову мнение других мне было бы интересно)

но я так ни разу не делал и таки задач как у тебя у меня небыло... я не очень уверен что Database это сущность

если database не сущность, то что?

даже если просто Embeddable

если database не сущность, то что?

ну окей, допустим сущность

весь вопрос - что такое DatabaseManager и что у него внутри?

много ли там внутри зависимостей?

а и еще важный вопрос - является ли эта сущность частью кор домена?

внутри передача шеллу запуск mysqldump,mysql

домен..

короч.... если не уверен - лучше пока передавай сервис как аргумент в сущность

приложение, база данных, файлы

и не выдумывай) проще будет потом откатывать задумку

приложение, база данных, файлы

предположим что у нас нет "базы данных" и мы пишем в лог

то есть например у тебя был бы сервис DatabaseManager и например...

на вход подается какой-то идентификатор базы и что сделать

и нам нужно вести лог этого добра. Поговорим о логах. Мы могли бы ввести TracableDatabaseManager какой как декоратор и там вести аудит действий над базой

допустим

отсюда вопрос - что у тебя внутри сущности Database?

какие данные из этой сущности нужны для проведения операций?

название базы внутри

самое простое

ну то есть данные для подключения например мы можем вынести в VO

пусть в VO

DBConnection

public function import(Dump $dump) { $dump->load($this->credentials); }

а Dump уже имеет внутри себя DatabaseManager или его часть, умеет из файла читать или это сделала фабрика какая

public function export(): Dump;

public function export(): Dump;

как реализовать?

export(DumpFactory $df)

только если так

не?

почему?

ты можешь лениво инициализировать его

ну я дума это все же разные штуки должны быть

ERROR: S client not available

короч хз

сложна

я бы тупо логгер юзал)

и декоратор

и VO с данными о базе

да у меня часто такие дилеммы возникают, как правильно mailer->send(email) или email->send()

mailer->send(email)

главное что бы не mailer->sendOneEmail, mailer->sendAnotherEmail

mailer->send(email)

почему так а не второй вариант? я не вижу этого

email = new Email(transport, message);

email->send();

допустим у тебя есть 100 разных имейлов

с каким вариантом связанность будет больше/меньше?

а как её посчитать?

email->send() - 100 классов зависят от транспорта. send(email) - 1 класс зависит от транспорта

а как её посчитать?

примитивно - сколько модулей разделяют одну и ту же зависимость. У тебя по хорошему число зависимостей между модулями должно быть сведено к разумному минимуму

email->send() - 100 классов зависят от транспорта. send(email) - 1 класс зависит от транспорта

не пойму, почему 100 классов?

ведь меняется message

а... у тебя текст сообщения тоже в аргументы..

одного класса

не, это тоже херня, абстракция которая ничего не делает

@fes0r ты летом на php framework days приезжаешь?

mailer->send(WelcomeMessage)

@fes0r ты летом на php framework days приезжаешь?

меня пока не звали

там уже c2p

ну и могу, могу про тесты вещать

не

давай за trunk based

про солид не хочу

давай за trunk based

ммм... думаешь?

ну у народа начнет пригорать)

ммм... пригорать...