This is the cleanest and most testable approach with predictable behavior across all AppHosts, IOCs, etc as it’s not reliant on external environment thread request context switching implementations. A more testable approach would be to pass in the Request properties you need instead of IRequest but as that requires more code/effort, I prefer to just pass in IRequest when needed.
The GlobalRequestFilter (or any other Request filter) is what you’d use to inject any per-request dependencies in IRequest.Items at the start of the Request pipeline.
Injecting IRequest works in both transient and singleton dependencies given it’s how to make dependencies ThreadSafe by passing in local dependencies as arguments.
Lazy Properties
Other than you could have a lazy property in a Service base class which constructs the dependency with the IRequest context which is how all multi-tenancy aware dependencies in Service.cs are implemented, e.g:
private IDbConnection db;
public virtual IDbConnection Db => db ?? (db = AppHost.GetDbConnection(Request));
Where your Services would be able to access it like a normal dependency:
public object Any(MyRequest request) => Db.SingleById<Table>(request.Id);
If you adopt this approach you’ll need to manually dispose of your dependency if it needs disposing. If you didn’t want a base class you could wrap the construction logic behind extension methods instead.