У меня есть приложение Laravel, которое требует получения некоторых конфигурационных варов, которые должны использоваться большинством моих контроллеров. Поэтому кажется, что это будет идеальное время для использования промежуточного программного обеспечения. Правильное ли использование промежуточного программного обеспечения? и если да, то когда промежуточное ПО получает конфигурационные вары, лучше ли добавлять их к объекту запроса, чтобы к ним мог обращаться мой контроллер? Спасибо любым респондентам. JДолжен ли я использовать промежуточное ПО Laravel?
ответ
IMO, middlewares сделаны для запросов на предварительную обработку, ограничивают доступ пользователей и другую связанную с безопасностью.
Я бы просто загрузил конфигурацию в основной класс контроллера и использовал его в расширяющих контроллерах.
Например:
базовый контроллер
namespace App\Http\Controllers;
uses goes here ...;
class Controller extends BaseController
{
protected $configs = [];
public function __construct() {
$this->loadConfigs();
}
protected function loadConfigs()
{
//read configuration files or tables in database
//and put the values into '$this->configs';
}
}
контроллер пользователя
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use App\Http\Requests;
class User extends Controller
{
public function index()
{
echo $this->configs['toolbar.color']; //just an example
}
}
Существует промежуточное программное обеспечение, чтобы проверить условия, прежде чем отправлять запросы на ваши контроллеры. Они используются для предварительной обработки ** и ** постпроцессинга. Это не связано с безопасностью, это связано с условием (одним условием может быть «пользователь должен быть аутентифицирован»). Его можно использовать для установки переменных и всего, что необходимо до того, как запрос достигнет контроллера. Этот комментарий здесь, чтобы подчеркнуть, что ваше утверждение о промежуточном использовании для безопасности это не так. –
Отличная благодарность Карлосу, что имеет смысл, поэтому в основном просто используйте промежуточное программное обеспечение для фильтрации и ставьте логику, которая может понадобиться большинству моих контроллеров в базовом контроллере. Это хорошо в моей голове :) – jon
Хотя я вижу, что NB не согласен. Итак, NB вы бы добавили мои требования в качестве midldleware? – jon
Не, определенно!
Фактически (исходя из того, что вы написали), наилучшим способом является создание сервисной службы и регистрация этой услуги в Service Container - App\Providers\AppServiceProvider
(в app/Providers/AppServiceProvider.php
).
Что-то вроде этого:
<?php
# The Config Service:
namespace App\Services;
/**
* Config Manager
*/
class Config
{
/** @var SomeDependency */
protected $dependency;
public function __construct(SomeDependency $dependency)
{
$this->dependency = $dependency;
}
public function getVar($var)
{
// ...
}
}
В прописанным:
<?php
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
class AppServiceProvider extends ServiceProvider
{
//...
/**
* Register any application services.
*
* @return void
*/
public function register()
{
$this->registerConfigManager();
}
public function registerConfigManager()
{
$this->app->singleton('config_service', function ($app) {
return new \App\Services\Config(new \SomeNamespace\SomeDependency);
});
}
//...
}
И теперь вы можете получить доступ к контейнеру службы через app()
, как это:
<?php
namespace App\Http\Controllers;
use App\Http\Controllers\Controller;
class MyController extends Controller
{
public function index(Request $request)
{
app('config_service')->getVar('key');
//...
}
}
Спасибо felipsmartins, согласны ли другие с тем, что это будет подходящее время для использования поставщика услуг? – jon
Это хорошее решение. – CarlosCarucce
@jon На самом деле, нет необходимости создавать поставщика услуг, а просто создавать класс, а затем регистрировать его как службу приложения в контейнере. Это просто и приятно. – felipsmartins
- 1. В Laravel, должен ли я проверить разрешение на контроллер, если вы уже проверяете промежуточное ПО?
- 2. Laravel - Почему промежуточное ПО пропускается?
- 3. LARAVEL: Как использовать промежуточное ПО по именованным маршрутам
- 4. Laravel 5.2.x отключить определенное промежуточное ПО
- 5. Должен ли я использовать промежуточное ПО для сжатия GZIP или нет?
- 6. Laravel 5 Ресурсы маршрута + промежуточное ПО
- 7. Невозможно использовать промежуточное ПО Multer
- 8. Должен ли я использовать `this` по умолчанию?
- 9. Должен ли я использовать ожидание по возвращении?
- 10. Динамическое промежуточное ПО для laravel 5
- 11. Как работает промежуточное ПО в Laravel 5?
- 12. Различные пользователи, промежуточное ПО Laravel 5
- 13. Условно использовать специальное промежуточное ПО
- 14. Как использовать промежуточное ПО 'OR' для маршрута laravel 5
- 15. Laravel 5.1: Как использовать промежуточное ПО в неявном контроллере?
- 16. Ионное промежуточное ПО, такое как Laravel
- 17. Послепродажное промежуточное ПО не запускается Laravel
- 18. Laravel Взаимозависимое промежуточное ПО вложенной группы маршрутов
- 19. Передача параметра в промежуточное ПО Laravel
- 20. промежуточное ПО, не работающее в просвете laravel
- 21. Должен ли я использовать jQuery.each()?
- 22. Должен ли я использовать RecyclerView?
- 23. Должен ли я использовать htmlspecialchars?
- 24. Должен ли я использовать Subversion?
- 25. Должен ли я использовать ссылку?
- 26. Должен ли я использовать const_cast?
- 27. Должен ли я использовать файлы сеялки gitignore в Laravel 5?
- 28. Должен ли я использовать модель EAV или нет в laravel?
- 29. Должен ли я использовать ownTo или hasOne в Laravel?
- 30. Должен ли я использовать коллектив laravel или другой компонент?
Являются config vars static или dynamic. – whoacowboy
Как только они определены в промежуточном программном обеспечении, они являются статическими. – jon
Можете ли вы добавить дополнительную информацию о том, для чего вы используете переменные, как долго они будут длиться и т. Д. – whoacowboy