Steven

The `ThreadScopedLifestyle` is a legacy lifestyle, which is included solely for backwards compatibility. For modern applications, you should primarily use the `AsyncScopedLifestyle` as this lifestyle works in both async and...

Theoretically, it would be possible to create a custom lifestyle, but there are many caveats in doing that. This is something I, therefore, don't advice. This 'scope skipping' is something...

With SignalR Core, it should be just a matter of replacing the default `IHubActivator` implementation with one that resolves from your favorite container, or creates hub instances using Pure DI.

> it looks like you're probably doing some trickery for it to automatically generate the controllers from the commands and queries. There are no controllers. The project is [Controllerless](http://github.com/dotnetjunkie/controllerless/). The...

I would suggest not passing along Expression objects with the query. Strive the messages you sent in your system (commands, queries, events) to be serializable. This means that they can...

> CQS separately handles Commands and Queries, with an optional Mediator for Queries to reduce dependencies as they are usually more numerous. Commands are usually more isolated, so less issue...

**TIP**: The discussion in #30 might also be of value to you.

> From this perspective it harder for me to make the argument to roll our own over using MediatR. As I said, you should pick the tools, patterns, and practices...

> Is there no way of hooking into an Application Start class or do I have to call the DI Container from every function? As mentioned by @CasperWSchmidt in [839](https://github.com/simpleinjector/SimpleInjector/issues/839#issuecomment-706001532),...

> I just meant the functions themselves were not testable or I don't know how to, for example testing for returning http codes like bad request, success etc. Not much...