Laravel Architecture - Где я могу поместить этот класс?

Question

Позвольте мне установить сцену:

У меня есть класс «Предмет», который имеет разные продукты питания (например, морковь, яблоки и т. Д.). Ссылка на таблицу "items". Здесь все хорошо.

В старой структуре, с которой я перемещаюсь, у меня также был класс «Полный белок», в котором объект Item был необходим в конструкторе. Этот объект «CompleteProtein» мог бы выполнять сложные запросы и методы и содержать общую информацию о том, что такое «Полный белок».

Где это вписывается в Laravel? Похоже, что это была бы красноречивая модель, поскольку она напрямую не связана с какой-либо таблицей в базе данных, , но она выполняет запросы базы данных. У него есть инъекция зависимостей (Item), а также сложные методы и константы в классе.

Должен ли я как-то вписаться в класс «Предмет»? Я чувствую, что это будет довольно грязно.

Answer 1

Для этого вам не нужны модели Eloquent. Я даже не использую Красноречивый (но абсолютно люблю остальную часть Laravel). Я даже не использую ORM (даже Doctrine2). Но если вы все еще хотите его использовать, считайте, что это часть вашей инфраструктуры, а не часть вашего бизнес-домена. Делайте звонки на звонках внутри Repository methods, например 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 написать класс, который имеет свои необходимые свойства и дать ему методы (так это not anemic), чтобы сформировать объект, который представляет собой хорошо -определенная «вещь» в вашем бизнесе. Отделите методы, необходимые для «сбора», например, действий. Это действия, в которых вы либо тянете что-то вроде базы данных и сохраняете что-то вроде базы данных. Отделите эти специальные методы и поместите их в репозиторий. В конечном итоге ваш код будет выглядеть примерно так:

$protein = new CompleteProtein($item, $blah, $blahblah); 
$protein->doSomethingWith("Apples"); 
$proteinRepository->persist($protein); 

Это отличный способ кодирования и инкапсуляции правил. Легко для нового разработчика увидеть все «вещи», которые составляют ваш бизнес. Если ваш разработчик хочет сделать некоторую настойчивость, вы можете поручить ему «пойти в хранилище». Нет одноразовых запросов здесь и там! Никаких вызовов ORM не требуется (притворяясь, что ваша реляционная база данных OO)! Вы также можете использовать метод на своих объектах домена, например markAsDeleted (или еще markAsErroneous), чтобы при отправке его в репозиторий с ->persist репозиторий мог искать флаг на вашем объекте и знать, чтобы его удалить. Это позволяет добавить логику к удалению.Изучите методы, используя класс Reflection PHP, чтобы предоставить Хранилищам доступ к объектам домена гидрата/обезвоживания. Zend Framework имеет хороший базовый, который мне нравится использовать. Хранилища также хороши для массовых собраний.

(Примечание: Существует папка я перечислял выше называется Queries для вас, чтобы создать классы для READ ситуаций запроса Вам не нужно увлажнять объекты целиком из хранилищ во многих случаях, когда вы просто желающих, чтобы отобразить информацию. на экране во всем приложении. «Разделение командного запроса».)

Answer 2

Это класс обслуживания. Независимо от вашего выбора структуры, я бы назвал ее как таковой.

Некоторые люди предпочитают папку (и пространство имен) под названием «Сервисы», другие предпочитают использовать немой подход, основанный на домене (возможно, это папка с именем «Protein», чтобы сохранить ее?), Но это зависит от вас.