Архитектура Laravel — Куда мне поместить этот класс?
Позвольте мне установить сцену:
У меня есть класс «Предмет», в котором есть разные продукты (например, морковь, яблоки и т. Д.).
Это ссылка на таблицу «items». Здесь все хорошо.
В старом фреймворке, из которого я выполняю миграцию, у меня также был класс «Complete Protein», в котором требовался объект Item в конструкторе. Этот объект «CompleteProtein» сможет выполнять сложные запросы и методы и содержать общую информацию о том, что такое «полный белок».
Где это вписывается в Laravel? Не похоже, что это будет красноречивая модель, поскольку она не имеет прямого отношения к какой-либо таблице в базе данных, но это делает запросы к базе данных. У него есть внедрение зависимостей (Item), а также сложные методы и константы в классе.
Должен ли я просто как-то вписать их в класс «Предмет»? Я чувствую, что это было бы довольно грязно.
Решение
Вам не нужны модели Eloquent для этого. Я даже не использую Eloquent (но очень люблю остальную часть Laravel). Я даже не использую ORM (даже Doctrine2). Но если вы все еще хотите использовать его, считайте, что это часть вашей инфраструктуры, а не часть вашего бизнеса. Делайте красноречивые звонки внутри Методы репозитория лайк findByEmail() или же save(), Многие люди делают репозиторий интерфейсом, чтобы они могли менять реализации в поставщиках услуг для тестирования (где вы используете реализацию репозитория в памяти, возможно, просто храните вещи в массивах). Опять же, я не буду возвращать Eloquent Models из этих репозиториев, но вместо этого верну объект гидратированного домена.
То, что вы описываете, является юридическое лицо в вашей сфере бизнеса. Возможно, это может быть доменная служба в вашем бизнес-домене, но она больше похожа на сущность (в DDD). Я бы поместил эту сущность в класс в таком месте:
app\
Domain\
CompleteProteins\
CompleteProtein.php
CompleteProteinRepository.php
Items\
Item.php
ItemRepository.php
(maybe some domain service classes here as well)
Http\
Queries\
Helpers\
Services\ (<-- maybe application level services here)
etc...
Теперь в вашем CompleteProtein.php написать класс, который имеет необходимые свойства и дать ему методы (так что это не анемичный) сформировать сущность, которая представляет собой четко определенную «вещь» в вашем бизнесе. Выделите методы, которые необходимы для «сбора» подобных действий. Это действия, в которых вы либо извлекаете что-то вроде базы данных, но сохраняете что-то вроде базы данных. Выделите эти специальные методы и поместите их в репозиторий. Ваш код в конечном итоге будет выглядеть примерно так:
$protein = new CompleteProtein($item, $blah, $blahblah);
$protein->doSomethingWith("Apples");
$proteinRepository->persist($protein);
Это отличный способ кодировать и инкапсулировать правила. Новому разработчику легко увидеть все «вещи», составляющие ваш бизнес. Если ваш разработчик хочет сделать что-то настойчивое, вы можете указать ему / ей «перейти в хранилище». Никаких разовых запросов тут и там! Никаких вызовов ORM не происходит (делая вид, что ваша реляционная база данных является OO)! Вы также можете иметь метод для ваших доменных объектов, таких как markAsDeleted (или еще лучше markAsErroneous) чтобы при отправке в хранилище ->persistрепозиторий может искать флаг на вашем объекте и знать, чтобы удалить его. Это позволяет вам добавлять логику в удаления. Изучите методы, использующие PHP-класс Reflection для предоставления хранилищам доступа к объектам домена с гидратацией / дегидратацией. У Zend Framework есть хорошая базовая версия, которую я люблю использовать. Хранилища также хороши для массовых расчетов.
(Примечание: есть папка, которую я перечислил выше Queries для вас, чтобы создать классы для чтения запросов ситуаций. Вам не нужно гидрировать полные сущности из ваших репозиториев во многих случаях, когда вы просто хотите отобразить информацию на экране во всем приложении. Google «Командный запрос разделения».)
Другие решения
Это класс обслуживания. Независимо от вашего выбора фреймворка, я бы назвал его таковым.
Некоторые люди предпочитают папку (и пространство имен) под названием «Службы», другие предпочитают использовать подход, основанный на немом домене (возможно, папку с именем «Белок», чтобы сохранить его?), Но это зависит от вас.
detector