weierophinney
commented
8 years ago @ZergMark There's a third approach as well: use a service object.
This solution would be similar to your (1) above, but instead of using a singleton, you'd have a service you manage in your container. Middleware that might inject it or consume it then will have that service injected, which means you'll write factories for them:
class MiddlewareUsingUserService
{
private $userService;
public function __construct(UserService $userService)
{
$this->userService = $userService;
}
public function __invoke($request, $response, $next)
{
// Pull the current identity:
$user = $this->userService->getIdentity();
// Or maybe inject it? (Never actually pull it from a query param, unvalidated!)
$this->userService->setIdentity($request->getQueryParams()['user_id']);
/* ... */
}
}
class MiddlewareUsingUserServiceFactory
{
public function __invoke($container)
{
return new MiddlewareusingUserService($container->get(UserService::class));
}
}The above is essentially how we provide the UrlHelper and ServerUrlHelper; I've done similarly on my own website when using opauth.
Option (2), injecting as request attributes, is where I was originally considering handling features like this, and, in point of fact, we use precisely that for communicating the RouteResult from the routing middleware to the dispatch middleware (and any middleware in-between). However, as you note, this can lead to bloating of the request, and becomes more of a "conventions-based" approach. As such, I prefer the dependency injection route in most cases, as it ensures a clean separation, while preventing usage of singletons.
ZergMark
basz
danizord
codeliner
A question of middleware philosophy. Hypothetical situation: I'm developing an API using Expressive with authentication/authorization. One of my prerouting (high priority I guess post-RC7) middlewares is an authentication class to determine if I'm a user. I will need user info later in my routed middleware. I can see two approaches, but not sure which would be more adherent to the "idea" of middleware.
1) The UserService instantiates a singleton User. Subsequent middleware injects UserService if it needs the info. This keeps the Request/Response objects "clean", but adds the needs for factories/callbacks for middleware that might otherwise just be invokable.
2) The Authentication middleware attaches a User object as a parameter onto the Request/Response object. This keeps the subsequent middleware "cleaner" by not having to inject the service all over the place and possibly cutting done on factory/callback complexity. This could however lead to the Request or Response object being the catchall for inter-middleware data.