Модели, хранилища, классы обслуживания и Работа (команды)
Мне нужна помощь в понимании того, какую роль каждый играет в большом приложении. Я начну сначала со сценария:
- как обычно будет пользователь
- пользователь должен иметь тип членства (бесплатный, базовый, бизнес).
- пользователь может иметь (не требуется) бизнес (пользователь имеет один или ноль бизнес)
- у пользователя может быть подписка (у пользователя одна или ноль подписок).
- подписка требует SubscriptionPlan, который связан с типом членства. Таким образом, тип членства «базовый» будет иметь в Stripe план «basic2015»; у «бизнеса» будет план «business2015».
- у пользователя есть адрес (пользователь много-много адресов)
- базовый пользователь должен иметь «личный» адрес в файле, в то время как бизнес-пользователь должен иметь «служебный» адрес в файле
- Есть и другие требования, но этого будет достаточно, чтобы получить лучшую картину
Пока у меня есть эти модели: пользователь, тип членства, бизнес, подписка, план подписки и адрес.
Некоторая бизнес-логика требует от меня по крайней мере следующих методов:
— пользователь isBusiness ()
— пользователь имеет адрес (тип), где тип (личный или служебный)
— тип членства getPlanForCurrentYear ()
— другие вещи требуются, но я остановлюсь здесь
Теперь пример: Джон регистрируется и обязан предоставить основную информацию (адрес электронной почты, пароль, имя). Он регистрируется как бизнес. После этого основного процесса регистрации он получает вход в систему и уведомляется, что он должен заполнить свой профиль, прежде чем получить доступ. Затем он должен предоставить деловую информацию (имя, веб-сайт, адрес электронной почты, телефон). Также мне нужен служебный адрес. Затем он должен подписаться на план на текущий год «business2015».
Все это мне удалось сделать, но я сделал это в своих контроллерах. Как некоторые предлагали в других постах, сначала сделайте так, чтобы это работало, а затем решите, нужно ли вам извлекать его в репозитории. Ну, я дошел до того, что я уверен, что мне нужно использовать репозитории, потому что это становится все более и более сложным, и я должен постоянно модифицировать свои контроллеры. Поэтому после долгих исследований я все еще не знаю, как сделать так, чтобы моя БД для пользовательского интерфейса работала в обоих направлениях без проблем.
Мои исследования привели меня к тому, что мне нужно использовать репозитории, может быть, классы обслуживания и рабочие места. Может кто-нибудь поделиться некоторыми мыслями о том, что мне нужно, чтобы иметь хорошую архитектуру?
-
Нужен ли мне репозиторий для каждой модели? Иметь интерфейс и абстрактный репозиторий с общими методами (all, getId, create, update, delete и т. Д.). Если так, как бы я связал хранилища между собой?
-
Нужны ли мне классы обслуживания (например, RegisterUser, CompleteProfile), которые управляют всеми задействованными репозиториями в определенное время?
-
Как мне использовать Джобс в этом сценарии? Отослать их из контроллера и внедрить репозиторий или класс обслуживания?
-
Есть ли где-нибудь пример больших приложений в Laravel (с открытым исходным кодом), на которые я могу взглянуть, чтобы понять некоторые из задействованных принципов?
Спасибо.
Решение
1 & 2. В данный момент вы запрашиваете базу данных через модели в контроллере. Начните с написания среднего слоя за пределами вашего контроллера. Это можно назвать сервисным уровнем. Итак, давайте предположим, что пользователь хочет зарегистрироваться, и отправляет в метод store вашего контроллера.
Создать UserService и добавить метод register, Позвольте вашему сервису поговорить с моделью. а ваш контроллер общается с сервисом.
UserController extends BaseController {
// Dependency injected the UserService
public function __construct(UserService $userService) {
$this->userService = $userService;
}
public function store(){
// validate input
// register the user
if (!$this->userService->register($input)) {
// return error
}
// return success
}
}
class UserService {
protected $user;
// Dependency injected the User model.
public function __construct(User $user) {
$this->user = $user;
}
public function register($input) {
return $this->user->create($input);
}
}
Как только вы это поняли, вы можете подумать об интерфейсах и абстрагировании следующего уровня.
Забудьте интерфейсы на время — вы, вероятно, еще не будете нуждаться в них. Интерфейсы действительно хороши, когда вы можете поменять реализацию дальше. например Сейчас вы используете Stripe Billing, но однажды вы можете захотеть использовать Paypal, поэтому вы программируете свою платежную систему на интерфейс, который по сути является контрактом, предусматривающим именно публичные методы, которые необходимо раскрыть.
-
Вам пока не нужна работа.
-
Согласно моему предыдущему комментарию, www.laracasts.com — действительно хороший ресурс.
Как только вы научитесь абстрагироваться от деталей вашего контроллера, все остальное должно произойти естественно и вовремя.
Другие решения
Других решений пока нет …