В моем проекте я решил использовать шаблон обслуживания (возможно, с шаблоном репозитория), чтобы иметь дело с бизнес-логикой в моем приложении. Я имею, например, модель Client
, которая представляет клиента и соответствующий ClientService
, который отвечает за специфическую бизнес-логику клиента.Laravel: Service/Repository Шаблон и код дублирования
class ClientService extends Service implements ClientServiceContract
{
public function create(array $attributes)
{
// Create a new client...
}
public function doSomethingElse(Client $client)
{
// Do something else
}
}
Скажем, например, у меня есть еще один сервис UserService
, который похож на ClientService
выше в том, что он имеет методы для создания и делать другие вещи, чтобы User
моделей.
Теперь, на моем сайте, представьте, что у меня есть форма, которую кто-то может заполнить, чтобы зарегистрировать свою заинтересованность в том, чтобы стать клиентом. В моей задней системе я хотел бы создать кнопку, которая берет интересную запись клиента ClientInterest
и создает Client
, User
, связывает два и, наконец, отправляет электронное письмо новому пользователю с подробной информацией.
Где, используя шаблон обслуживания, было бы лучше всего поставить эту логику?
Я рассмотрел:
Создание службы и метод
ClientInterestService::createClientAndUser(...)
, который будет использоватьClientService
иUserService
классы для созданияClient
иUser
экземпляров, а затем осуществляют связь перед запуском события, которое посылает Эл. адрес. Этот подход означает, что я не дублирую код, однако я объединяю классы вместе, и я нарушаю некоторые принципы SOLID. Я не уверен, но у меня такое чувство, что это не будет здорово для тестирования.Как описано выше, создать класс обслуживания и метод для выполнения логики, но вместо того, чтобы использовать два других услуг, я хотел бы написать логику, чтобы создать
Client
иUser
экземпляров, осуществлять связь и инициировать событие для отправки электронной почты. Этот подход кажется более приятным, мой код более слабо связан, и я не нарушаю никаких принципов SOLID, однако я потенциально дублирую код.Проще говоря, логика, которую я бы имел в
ClientInterestService::createClientAndUser(...)
в моем контроллере. Выполнение этого будет означать, что у меня есть бизнес-логика в моем контроллере, которая поражает точку зрения на наличие сервисов.
Приятный подход к нему. Но как бы вы приблизились к нему, если бы у меня было два разных класса обслуживания «ClientService» и «UserService», каждый из которых имел свои методы 'create'? – Jonathon
Я отредактировал свой ответ, чтобы дать обзор того, как вы можете обрабатывать несколько сервисов. Это хороший подход до тех пор, пока вам не понадобится вводить много классов для обработки действия. (возможно, 5 или более?). Если дело дошло до этого, вы должны переделать иерархию. – jakehallas
Спасибо за обновление. Мне очень нравится ваш подход к созданию «действия», который может принимать и использовать службы таким образом. Возможно, я мог бы написать более общие, сущностные методы в моих классах услуг, а затем реализовать действия, которые принимают и используют эти службы для выполнения необходимых функций. Я был бы склонен писать действия почти для всех, поскольку это кажется мне более естественным. Он немного похож на архитектуру стиля командной шины, к которой я привык в ранних версиях Laravel, но намного чище. – Jonathon