simple injector - inject into IHttpHandler
I'm trying to embed SimpleInjector in my WCF project (I've followed the instructions here). Till now everything went well except from IHttpHandler issue:
the current implementation uses IHttpHandler which in turn uses MyServiceWrapper static instance:
public class IsAliveHandler : IHttpHandler
private const string SERVER_ERROR = "Bad";
private const string SERVER_OK = "OK";
public void ProcessRequest(HttpContext context)
var quoteSucceeded = false;
var isLastLoginSucceeded = MyServiceWrapperContainer.Manager.IsLastLoginSucceeded;
//More logic here ...
Now, since I moved my application to use the SimpleInjector DI mechanism I can't use such a static access since I want to use the same instance as held by the DI container.
constructor injection here gets exception:
[MissingMethodException: Constructor on type '***.Applications.MyServiceWrapperService.KeepAliveHandler.IsAliveHandler' not found.]
Is there a way to use container in such scenario? Are there alternatives?
Generally, I can understand that such problem is smell of using state, but currently this is the requirement.
c# wcf dependency-injection simple-injector ihttphandler
add a comment |
I'm trying to embed SimpleInjector in my WCF project (I've followed the instructions here). Till now everything went well except from IHttpHandler issue:
the current implementation uses IHttpHandler which in turn uses MyServiceWrapper static instance:
public class IsAliveHandler : IHttpHandler
private const string SERVER_ERROR = "Bad";
private const string SERVER_OK = "OK";
public void ProcessRequest(HttpContext context)
var quoteSucceeded = false;
var isLastLoginSucceeded = MyServiceWrapperContainer.Manager.IsLastLoginSucceeded;
//More logic here ...
Now, since I moved my application to use the SimpleInjector DI mechanism I can't use such a static access since I want to use the same instance as held by the DI container.
constructor injection here gets exception:
[MissingMethodException: Constructor on type '***.Applications.MyServiceWrapperService.KeepAliveHandler.IsAliveHandler' not found.]
Is there a way to use container in such scenario? Are there alternatives?
Generally, I can understand that such problem is smell of using state, but currently this is the requirement.
c# wcf dependency-injection simple-injector ihttphandler
add a comment |
I'm trying to embed SimpleInjector in my WCF project (I've followed the instructions here). Till now everything went well except from IHttpHandler issue:
the current implementation uses IHttpHandler which in turn uses MyServiceWrapper static instance:
public class IsAliveHandler : IHttpHandler
private const string SERVER_ERROR = "Bad";
private const string SERVER_OK = "OK";
public void ProcessRequest(HttpContext context)
var quoteSucceeded = false;
var isLastLoginSucceeded = MyServiceWrapperContainer.Manager.IsLastLoginSucceeded;
//More logic here ...
Now, since I moved my application to use the SimpleInjector DI mechanism I can't use such a static access since I want to use the same instance as held by the DI container.
constructor injection here gets exception:
[MissingMethodException: Constructor on type '***.Applications.MyServiceWrapperService.KeepAliveHandler.IsAliveHandler' not found.]
Is there a way to use container in such scenario? Are there alternatives?
Generally, I can understand that such problem is smell of using state, but currently this is the requirement.
c# wcf dependency-injection simple-injector ihttphandler
I'm trying to embed SimpleInjector in my WCF project (I've followed the instructions here). Till now everything went well except from IHttpHandler issue:
the current implementation uses IHttpHandler which in turn uses MyServiceWrapper static instance:
public class IsAliveHandler : IHttpHandler
private const string SERVER_ERROR = "Bad";
private const string SERVER_OK = "OK";
public void ProcessRequest(HttpContext context)
var quoteSucceeded = false;
var isLastLoginSucceeded = MyServiceWrapperContainer.Manager.IsLastLoginSucceeded;
//More logic here ...
Now, since I moved my application to use the SimpleInjector DI mechanism I can't use such a static access since I want to use the same instance as held by the DI container.
constructor injection here gets exception:
[MissingMethodException: Constructor on type '***.Applications.MyServiceWrapperService.KeepAliveHandler.IsAliveHandler' not found.]
Is there a way to use container in such scenario? Are there alternatives?
Generally, I can understand that such problem is smell of using state, but currently this is the requirement.
c# wcf dependency-injection simple-injector ihttphandler
c# wcf dependency-injection simple-injector ihttphandler
edited Nov 12 at 12:50
asked Nov 12 at 12:13
Roni
8013
8013
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Your IsAliveHandler
can't have any constructor arguments (this is a constraint of your application framework).
Instead, you should make your IsAliveHandler
a Humble Object and consider it to be part of your Composition Root.
This means that you extract all interesting logic out of the IsAliveHandler
(e.g. into an IsAliveService
) and change IsAliveHandler
to something as follows:
public class IsAliveHandler : IHttpHandler
public void ProcessRequest(HttpContext context)
Bootstrapper.Container.GetInstance<IsAliveService>().Process(context);
In other words, the only thing you let the IsAliveHandler
do is to request the service from the DI Container and invoke the appropriate method on that resolved service.
Do note that IsAliveHandler
should stay completely stateless: the resolve IsAliveService
should nowhere be stored. You should leave it up to the DI Container to provide you with the correct instance.
In case this operation runs outside the context of a Simple Injector Scope
, you might to wrap the operation inside such a Scope
:
public void ProcessRequest(HttpContext context)
using (AsyncScopedLifestyle.BeginScope(Bootstrapper.Container))
Bootstrapper.Container.GetInstance<IsAliveService>().Process(context);
Thanks for your good insights! Regarding the service locator you suggested in the Handler: Currently I use the container in the composition root as:public class Global : System.Web.HttpApplication { private readonly Container _container = new Container();
. As you wrote in your code:Bootstrapper.Container.GetInstance
- Should I move the container to the static Bootstrapper class?
– Roni
Nov 12 at 14:25
2
You can place the Container abywhere you like, as long as only the start-up path of the application (can) gets a hold of it. Using the Container within the Composition Root is not the Service Locator anti-pattern. Your handler can be considered part of the Composition Root. That's why you should extract all (business) logic out of the handler.
– Steven
Nov 12 at 14:46
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53261975%2fsimple-injector-inject-into-ihttphandler%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Your IsAliveHandler
can't have any constructor arguments (this is a constraint of your application framework).
Instead, you should make your IsAliveHandler
a Humble Object and consider it to be part of your Composition Root.
This means that you extract all interesting logic out of the IsAliveHandler
(e.g. into an IsAliveService
) and change IsAliveHandler
to something as follows:
public class IsAliveHandler : IHttpHandler
public void ProcessRequest(HttpContext context)
Bootstrapper.Container.GetInstance<IsAliveService>().Process(context);
In other words, the only thing you let the IsAliveHandler
do is to request the service from the DI Container and invoke the appropriate method on that resolved service.
Do note that IsAliveHandler
should stay completely stateless: the resolve IsAliveService
should nowhere be stored. You should leave it up to the DI Container to provide you with the correct instance.
In case this operation runs outside the context of a Simple Injector Scope
, you might to wrap the operation inside such a Scope
:
public void ProcessRequest(HttpContext context)
using (AsyncScopedLifestyle.BeginScope(Bootstrapper.Container))
Bootstrapper.Container.GetInstance<IsAliveService>().Process(context);
Thanks for your good insights! Regarding the service locator you suggested in the Handler: Currently I use the container in the composition root as:public class Global : System.Web.HttpApplication { private readonly Container _container = new Container();
. As you wrote in your code:Bootstrapper.Container.GetInstance
- Should I move the container to the static Bootstrapper class?
– Roni
Nov 12 at 14:25
2
You can place the Container abywhere you like, as long as only the start-up path of the application (can) gets a hold of it. Using the Container within the Composition Root is not the Service Locator anti-pattern. Your handler can be considered part of the Composition Root. That's why you should extract all (business) logic out of the handler.
– Steven
Nov 12 at 14:46
add a comment |
Your IsAliveHandler
can't have any constructor arguments (this is a constraint of your application framework).
Instead, you should make your IsAliveHandler
a Humble Object and consider it to be part of your Composition Root.
This means that you extract all interesting logic out of the IsAliveHandler
(e.g. into an IsAliveService
) and change IsAliveHandler
to something as follows:
public class IsAliveHandler : IHttpHandler
public void ProcessRequest(HttpContext context)
Bootstrapper.Container.GetInstance<IsAliveService>().Process(context);
In other words, the only thing you let the IsAliveHandler
do is to request the service from the DI Container and invoke the appropriate method on that resolved service.
Do note that IsAliveHandler
should stay completely stateless: the resolve IsAliveService
should nowhere be stored. You should leave it up to the DI Container to provide you with the correct instance.
In case this operation runs outside the context of a Simple Injector Scope
, you might to wrap the operation inside such a Scope
:
public void ProcessRequest(HttpContext context)
using (AsyncScopedLifestyle.BeginScope(Bootstrapper.Container))
Bootstrapper.Container.GetInstance<IsAliveService>().Process(context);
Thanks for your good insights! Regarding the service locator you suggested in the Handler: Currently I use the container in the composition root as:public class Global : System.Web.HttpApplication { private readonly Container _container = new Container();
. As you wrote in your code:Bootstrapper.Container.GetInstance
- Should I move the container to the static Bootstrapper class?
– Roni
Nov 12 at 14:25
2
You can place the Container abywhere you like, as long as only the start-up path of the application (can) gets a hold of it. Using the Container within the Composition Root is not the Service Locator anti-pattern. Your handler can be considered part of the Composition Root. That's why you should extract all (business) logic out of the handler.
– Steven
Nov 12 at 14:46
add a comment |
Your IsAliveHandler
can't have any constructor arguments (this is a constraint of your application framework).
Instead, you should make your IsAliveHandler
a Humble Object and consider it to be part of your Composition Root.
This means that you extract all interesting logic out of the IsAliveHandler
(e.g. into an IsAliveService
) and change IsAliveHandler
to something as follows:
public class IsAliveHandler : IHttpHandler
public void ProcessRequest(HttpContext context)
Bootstrapper.Container.GetInstance<IsAliveService>().Process(context);
In other words, the only thing you let the IsAliveHandler
do is to request the service from the DI Container and invoke the appropriate method on that resolved service.
Do note that IsAliveHandler
should stay completely stateless: the resolve IsAliveService
should nowhere be stored. You should leave it up to the DI Container to provide you with the correct instance.
In case this operation runs outside the context of a Simple Injector Scope
, you might to wrap the operation inside such a Scope
:
public void ProcessRequest(HttpContext context)
using (AsyncScopedLifestyle.BeginScope(Bootstrapper.Container))
Bootstrapper.Container.GetInstance<IsAliveService>().Process(context);
Your IsAliveHandler
can't have any constructor arguments (this is a constraint of your application framework).
Instead, you should make your IsAliveHandler
a Humble Object and consider it to be part of your Composition Root.
This means that you extract all interesting logic out of the IsAliveHandler
(e.g. into an IsAliveService
) and change IsAliveHandler
to something as follows:
public class IsAliveHandler : IHttpHandler
public void ProcessRequest(HttpContext context)
Bootstrapper.Container.GetInstance<IsAliveService>().Process(context);
In other words, the only thing you let the IsAliveHandler
do is to request the service from the DI Container and invoke the appropriate method on that resolved service.
Do note that IsAliveHandler
should stay completely stateless: the resolve IsAliveService
should nowhere be stored. You should leave it up to the DI Container to provide you with the correct instance.
In case this operation runs outside the context of a Simple Injector Scope
, you might to wrap the operation inside such a Scope
:
public void ProcessRequest(HttpContext context)
using (AsyncScopedLifestyle.BeginScope(Bootstrapper.Container))
Bootstrapper.Container.GetInstance<IsAliveService>().Process(context);
answered Nov 12 at 13:53
Steven
126k17212330
126k17212330
Thanks for your good insights! Regarding the service locator you suggested in the Handler: Currently I use the container in the composition root as:public class Global : System.Web.HttpApplication { private readonly Container _container = new Container();
. As you wrote in your code:Bootstrapper.Container.GetInstance
- Should I move the container to the static Bootstrapper class?
– Roni
Nov 12 at 14:25
2
You can place the Container abywhere you like, as long as only the start-up path of the application (can) gets a hold of it. Using the Container within the Composition Root is not the Service Locator anti-pattern. Your handler can be considered part of the Composition Root. That's why you should extract all (business) logic out of the handler.
– Steven
Nov 12 at 14:46
add a comment |
Thanks for your good insights! Regarding the service locator you suggested in the Handler: Currently I use the container in the composition root as:public class Global : System.Web.HttpApplication { private readonly Container _container = new Container();
. As you wrote in your code:Bootstrapper.Container.GetInstance
- Should I move the container to the static Bootstrapper class?
– Roni
Nov 12 at 14:25
2
You can place the Container abywhere you like, as long as only the start-up path of the application (can) gets a hold of it. Using the Container within the Composition Root is not the Service Locator anti-pattern. Your handler can be considered part of the Composition Root. That's why you should extract all (business) logic out of the handler.
– Steven
Nov 12 at 14:46
Thanks for your good insights! Regarding the service locator you suggested in the Handler: Currently I use the container in the composition root as:
public class Global : System.Web.HttpApplication { private readonly Container _container = new Container();
. As you wrote in your code: Bootstrapper.Container.GetInstance
- Should I move the container to the static Bootstrapper class?– Roni
Nov 12 at 14:25
Thanks for your good insights! Regarding the service locator you suggested in the Handler: Currently I use the container in the composition root as:
public class Global : System.Web.HttpApplication { private readonly Container _container = new Container();
. As you wrote in your code: Bootstrapper.Container.GetInstance
- Should I move the container to the static Bootstrapper class?– Roni
Nov 12 at 14:25
2
2
You can place the Container abywhere you like, as long as only the start-up path of the application (can) gets a hold of it. Using the Container within the Composition Root is not the Service Locator anti-pattern. Your handler can be considered part of the Composition Root. That's why you should extract all (business) logic out of the handler.
– Steven
Nov 12 at 14:46
You can place the Container abywhere you like, as long as only the start-up path of the application (can) gets a hold of it. Using the Container within the Composition Root is not the Service Locator anti-pattern. Your handler can be considered part of the Composition Root. That's why you should extract all (business) logic out of the handler.
– Steven
Nov 12 at 14:46
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53261975%2fsimple-injector-inject-into-ihttphandler%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown