разница между использованием сеанса через экземпляр HTTP-запроса и использованием глобального помощника сеанса в Laravel

Сервисный контейнер является основой архитектуры Laravel. Все сервисы, компоненты и зависимости зарегистрированы там, и вы можете запросить любой из них, когда вам это нужно.

Но Laravel предлагает более одного способа «попросить об этом». У вас есть глобальные вспомогательные функции, у вас есть фасады, у вас есть «правильная», «более чистая» инъекция экземпляра компонента в сигнатуре метода. Я думаю, что большая часть философии Laravel – это чистый, простой, интуитивно понятный API. И в этом случае вы можете отказаться от своих личных предпочтений, чтобы определить, что такое «чистое и легкое», и что бы ни было вашим стилем, по определению, интуитивно понятным для вас.

Я знаю, что в сообществе PHP были горячие дебаты о том, какой метод является «лучшим», фасады были спорными, традиционная инъекция зависимости ООП-пуристы говорят, что единственным правильным способом может быть инъекция объекта с помощью сигнатуры метода контроллера …

В конце концов, любой из этих различных методов просто захватывает объект из одного и того же контейнера-контейнера. Это не имеет разницы в производительности (я уверен, что два вызова функции косвенности не повлияют на вашу производительность) или иным образом. Итак, используйте то, что лучше подходит вашему стилю. Я лично делаю «правильную» инъекцию в любом случае, если у меня типичный контроллер, но, возможно, я использую глобальный помощник, если он делает более чистым, более читаемым кодом в его контексте.

 <?php namespace App\Http\Controllers; use Illuminate\Contracts\Session\Session; use Facades\Illuminate\Contracts\Session\Session as SessionRealTimeFacade; use Illuminate\Http\Request; use Illuminate\Support\Facades\Input; use Illuminate\Support\Facades\Request as RequestFacade; use Illuminate\Support\Facades\Session as SessionFacade; use PHPUnit\Framework\Assert; class TestController extends Controller { public function sessionTest(Request $request, Session $session) { $options = [ $request->session()->get('_token'), session()->get('_token'), session('_token'), $session->get('_token'), SessionFacade::get('_token'), SessionRealTimeFacade::get('_token'), app('session')->get('_token'), ]; array_reduce( $options, function ($one, $other) { Assert::assertEquals($one, $other); return $other; }, array_shift($options) ); return 'All tests passed!'; } } 

И, кстати, как вы видите, у вас есть не более двух вариантов 🙂

Конечно, это не относится только к сеансам, то же самое касается получения данных запроса, получения соединения с БД и т. Д.

(Кроме того, я думаю, что у вас нет фасадов в режиме реального времени в 5.3)

$ request-> session () и session () – это то же самое.

Существует два основных способа работы с данными сеанса в Laravel: глобальная функция в помощнике session () и через экземпляр $ request.

вы можете использовать его так

 public function testMyMethod(Request $request){ //$userExist = $request->session()->exists('user_id'); $userExist = $request->session()->has('user_id'); } 

1. Документация Laravel

Согласно Laravel Docs – https://laravel.com/docs/5.3/session, « существует небольшая практическая разница между использованием сеанса через экземпляр HTTP-запроса и использованием глобального помощника сеанса», и оба они могут быть проверены.

->assertSessionHas($key, $value = null);

2. Laravel Up & Running – Мэтт Штауффер

В своей книге (стр. 320-) Мэтт рассказывает о различных способах доступа к информации о сеансе:

• Использование фасада Session

  session()->get('user_id');

• Использование метода session() для любого объекта Illuminate Request

  Route::get('dashboard', function(Request $request) { $request->session()->get('user_id'); });

• Внедрить экземпляр Illuminate\Session\Store

  Route::get('dashboard', function(Illuminate\Session\Store $session) { return $session->get('user_id'); });

• Использование глобального помощника session()

  $value = session()->get('key); $value = session('key);

Его последний комментарий: если вы новичок в Laravel и не знаете, что использовать, я бы рекомендовал использовать глобальный помощник .

Поэтому я не буду беспокоиться о различиях и просто идти с тем, что «чувствует себя хорошо» для вас. Если у вас нет предпочтений в любом случае, пойдите с рекомендацией Мэтта Штаффера.

На самом деле родной PHP-сеанс – это готовое решение по сравнению с лучшей реализацией от Laravel и Symfony, которые задумались над этим. Прочтите объяснение в записи конфигурации конфигурации Symfony Session, и вы поймете, что я думаю. Так что есть разница, но в том, как это мыслится и реализуется. С точки зрения производительности я думаю, что их немного. Я позволю вам сделать ваши выводы. Еще одна запись, которая помогает в руководстве PHP

В конечном счете, как обычно вы используете эти два варианта, нет никакой практической разницы между $request->session() и session() . Однако они технически не возвращают одни и те же объекты.

session() вернет SessionManager . $request->session() вернет сеанс Store .

Store фактически является объектом, который содержит данные сеанса.

SessionManager – это объект, который управляет доступным сеансом Store s. Большинство приложений будут использовать только один хранилище сеансов (по умолчанию).

Причина, по которой они, похоже, действуют как один и тот же объект, заключается в том, что при вызове метода в SessionManager , который не существует, он пересылает этот метод в Store по умолчанию.

Итак, в вашем примере вы используете метод exists() . Этот метод не существует в SessionManager . Итак, если вы должны были вызвать session()->exists('user_id') , он переадресовал бы этот вызов вниз в Store сеансов по умолчанию, и это было бы эквивалентно вызову $request->session()->exists('user_id') .

Можно утверждать, что непосредственное использование $request->session() более подходит при попытке доступа к данным сеанса, поскольку это то, что возвращается, и не требует вызова дополнительной функции пересылки. Тем не менее, вам решать взвешивать плюсы и минусы, чтобы определить, какой метод использовать.