Я пытаюсь зарегистрировать все действия, которые делают пользователи (login / logout / CRUD), в таблицу журналов в моей базе данных, и из того, что я видел, события выглядят правильно.
Я добавил метод did($action) модели User, который регистрирует действие для базы данных для данного пользователя.
Вот что у меня до сих пор:
EventServiceProvider.php
namespace App\Events; use Illuminate\Support\ServiceProvider; class EventServiceProvider extends ServiceProvider { public function register() { $this->app->events->subscribe(new UserEventSubscriber); } }
UserEventSubscriber.php
namespace App\Events; class UserEventSubscriber { public function login(\User $user) { return $user->did('logged_in'); } public function logout(\User $user) { return $user->did('logged_out'); } public function subscribe($events) { $events->listen('user.login', 'App\Events\UserEventSubscriber@login'); $events->listen('user.logout', 'App\Events\UserEventSubscriber@logout'); } }
Чтобы зарегистрировать действие:
Event::fire('user.logout', array(Auth::user()));
Я все еще пытаюсь обдумать поставщиков услуг, поэтому я мог бы быть очень неактивным.
Мои вопросы:
1) Правильно ли используется поставщик услуг или это?
2) Есть ли лучший подход, который не требует вручную передавать Auth::user() в событие каждый раз?
3) На каком уровне должны быть уволены события? Я склоняюсь к модели, когда это возможно, поскольку это обеспечило бы более полезные журналы из массовых действий. В противном случае есть контроллер или репозиторий.
4) Эти события необходимы только в области администратора (/ admin / *). Было бы полезно каким-то образом ограничить это только той частью сайта?
5) Мои поиски, касающиеся регистрации действий пользователя, были очень бесплодными. Это то, что разработчики не делают? Если да, что они делают?
Is a service provider the right thing to use or this?
Да, неплохо использовать service provider для загрузки, но не обязательно. Если вы хотите, вы можете полностью исключить EventServiceProvider service provider и можете сделать то же самое из файла app/start/global.php используя это:
$app->events->subscribe(new Events\UserEventSubscriber);
Поскольку $app является глобальной переменной, поэтому вы можете использовать ее здесь, но это не более чистый способ сделать это в этом global.php ( global.php ), но service provider – это всего лишь аккуратный и чистый способ загружать вещи (например, включая файлы php используя include "someClass.php" ), потому что Laravel называет метод register определенный в каждом классе service provider во время процесса загрузки фреймворка, поэтому разработчики могут выполнять некоторую загрузку / инициализацию / включение и подобные вещи до того, как приложение отправит маршрут.
Есть ли лучший подход, который не требует вручную передавать Auth :: user () в событие каждый раз?
Существуют и другие способы, но в этом случае придерживайтесь вашего текущего подхода, потому что зависимость – это Auth::user() означает, что пользователь в настоящее время вошел в систему, поэтому лучше использовать его вручную или вы также можете использовать \Auth::user()->did() прямо вот так:
public function login() { return \Auth::user()->did('logged_in'); }
Это другой случай, но Laravel обеспечивает хороший способ автоматического разрешения зависимостей с использованием контейнера IoC при вводе любой зависимости в классе __constructor , например:
class SomeClass { public function __construct(User $user) { $this->use = $user; } }
В этом случае вам не нужно передавать класс User при использовании этого класса, потому что контейнер IoC может автоматически вводить зависимость, когда среда создает экземпляр, но в вашем случае он зависит от Auth::user()/looged in user так что это немного другая вещь, поэтому вручную сделайте это или напрямую используйте Auth::user()->did() .
На каком уровне должны быть запущены события? Я склоняюсь к модели, когда это возможно, поскольку это обеспечило бы более полезные журналы из массовых действий. В противном случае есть контроллер или репозиторий.
Для этого нет level , это зависит от ваших потребностей и предпочтений, а может быть и от архитектуры приложения. Собственно, вы можете создавать свое приложение даже без использования events .
Эти события необходимы только в области администратора (/ admin / *). Было бы полезно каким-то образом ограничить это только той частью сайта?
Может быть, вы можете, но не нужно, не очень большое дело IMO .
Мои поиски, касающиеся регистрации действий пользователя, были очень бесплодными. Это то, что разработчики не делают? Если да, что они делают?
Не совсем уверен, о чем вы говорите, но если вы говорите о logging действий пользователя, то ответ: depends . Однажды я обратился в туристическое агентство, и в их приложении logging действий пользователя была очень важна, поэтому я зарегистрировал почти все, что пользователь делает после того, как он (а) войдет в систему, например: получение платежа от клиента, продажа билета, их (сотрудники / пользователи) входить in/out систему in/out чтобы высший орган мог проверить их действия.
Не стесняйтесь о том, что делают другие, узнайте, что вам нужно сделать, понять ваши требования и соответствующим образом развиться.