Mixing
Get ModelState outside of controller and ActionFilter
Is there a way to access the ModelStateDictionary from DI (outside of a Controller or ActionFilter)? I think I can make an ActionFilter that stores a reference to the ModelStateDictionary somewhere, so I can access it later elsewhere, but I want to know if there's a conventional way to access it, like there's IHttpContextAccessor for HttpContext.
We have a web app that is a client to our api. The reason I want to do this is because I want to automatically add errors to the web app's ModelState from a DelegatingHandler used by our API client (a typed http client). The handler would watch every response from the API and, for the ones applicable (400 responses with custom error codes in the body, like "Name already taken"), add a message to the ModelState.
So far I've tried asking for a ControllerContext, but it seems to be always null.
var controllerContext = _serviceProvider.GetService<ControllerContext>();
controllerContext?.ModelState.AddModelError("", result.ErrorMessage);
I've also looked at all the registered services using the VS debugger, but I couldn't find anything promising.
Side note (quite a big one) regarding comments about SRP and separation of concerns: I don't think this violates SRP. The API client is a generic client implementation of our API, which can be consumed from anywhere (we currently use it on Xamarin and an ASP.NET Core MVC Web app - the one mentioned in this very question). However, the API client expects a HttpClient in its constructor, which means that its behavior can be modified by its consumers.
The Web App, for example, uses DI to provide the HttpClient the API client needs. That HttpClient is setup to use two delegating handlers, one of which is the one I've described in this question.
As to whether or not ModelState should be manipulated outside of controllers: well, that is exactly what libraries like FluentValidation (and ASP.NET default validation) does.
As to whether or not ModelState should be manipulated in a DelegatingHandler: I think this is a somewhat more valid discussion. However, no one has really presented no argument as to why this is bad.
As to wether or not this should be done "automatically": I think it's better having the code in one place than having to remember to do this every time in every action in every call to the api.
As to whether or not these messages should be even put into the ModelState: well, if I go into that here this side note would become too big. Also, no one has really argued about this, so...
c# asp.net-core httpclientfactory
asked Jan 2 at 14:27
andre_ss6andre_ss6
69511123
add a comment |
Is there a way to access the ModelStateDictionary from DI (outside of a Controller or ActionFilter)? I think I can make an ActionFilter that stores a reference to the ModelStateDictionary somewhere, so I can access it later elsewhere, but I want to know if there's a conventional way to access it, like there's IHttpContextAccessor for HttpContext.
We have a web app that is a client to our api. The reason I want to do this is because I want to automatically add errors to the web app's ModelState from a DelegatingHandler used by our API client (a typed http client). The handler would watch every response from the API and, for the ones applicable (400 responses with custom error codes in the body, like "Name already taken"), add a message to the ModelState.
So far I've tried asking for a ControllerContext, but it seems to be always null.
var controllerContext = _serviceProvider.GetService<ControllerContext>();
controllerContext?.ModelState.AddModelError("", result.ErrorMessage);
I've also looked at all the registered services using the VS debugger, but I couldn't find anything promising.
Side note (quite a big one) regarding comments about SRP and separation of concerns: I don't think this violates SRP. The API client is a generic client implementation of our API, which can be consumed from anywhere (we currently use it on Xamarin and an ASP.NET Core MVC Web app - the one mentioned in this very question). However, the API client expects a HttpClient in its constructor, which means that its behavior can be modified by its consumers.
The Web App, for example, uses DI to provide the HttpClient the API client needs. That HttpClient is setup to use two delegating handlers, one of which is the one I've described in this question.
As to whether or not ModelState should be manipulated outside of controllers: well, that is exactly what libraries like FluentValidation (and ASP.NET default validation) does.
As to whether or not ModelState should be manipulated in a DelegatingHandler: I think this is a somewhat more valid discussion. However, no one has really presented no argument as to why this is bad.
As to wether or not this should be done "automatically": I think it's better having the code in one place than having to remember to do this every time in every action in every call to the api.
As to whether or not these messages should be even put into the ModelState: well, if I go into that here this side note would become too big. Also, no one has really argued about this, so...
c# asp.net-core httpclientfactory
asked Jan 2 at 14:27
andre_ss6andre_ss6
69511123
why are you not using ActionFilterAttribute instead of DelegatingHandler ?
– Manoj Choudhari
Jan 2 at 14:44
add a comment |
Is there a way to access the ModelStateDictionary from DI (outside of a Controller or ActionFilter)? I think I can make an ActionFilter that stores a reference to the ModelStateDictionary somewhere, so I can access it later elsewhere, but I want to know if there's a conventional way to access it, like there's IHttpContextAccessor for HttpContext.
We have a web app that is a client to our api. The reason I want to do this is because I want to automatically add errors to the web app's ModelState from a DelegatingHandler used by our API client (a typed http client). The handler would watch every response from the API and, for the ones applicable (400 responses with custom error codes in the body, like "Name already taken"), add a message to the ModelState.
So far I've tried asking for a ControllerContext, but it seems to be always null.
var controllerContext = _serviceProvider.GetService<ControllerContext>();
controllerContext?.ModelState.AddModelError("", result.ErrorMessage);
I've also looked at all the registered services using the VS debugger, but I couldn't find anything promising.
Side note (quite a big one) regarding comments about SRP and separation of concerns: I don't think this violates SRP. The API client is a generic client implementation of our API, which can be consumed from anywhere (we currently use it on Xamarin and an ASP.NET Core MVC Web app - the one mentioned in this very question). However, the API client expects a HttpClient in its constructor, which means that its behavior can be modified by its consumers.
The Web App, for example, uses DI to provide the HttpClient the API client needs. That HttpClient is setup to use two delegating handlers, one of which is the one I've described in this question.
As to whether or not ModelState should be manipulated outside of controllers: well, that is exactly what libraries like FluentValidation (and ASP.NET default validation) does.
As to whether or not ModelState should be manipulated in a DelegatingHandler: I think this is a somewhat more valid discussion. However, no one has really presented no argument as to why this is bad.
As to wether or not this should be done "automatically": I think it's better having the code in one place than having to remember to do this every time in every action in every call to the api.
As to whether or not these messages should be even put into the ModelState: well, if I go into that here this side note would become too big. Also, no one has really argued about this, so...
c# asp.net-core httpclientfactory
asked Jan 2 at 14:27
andre_ss6andre_ss6
69511123
Is there a way to access the ModelStateDictionary from DI (outside of a Controller or ActionFilter)? I think I can make an ActionFilter that stores a reference to the ModelStateDictionary somewhere, so I can access it later elsewhere, but I want to know if there's a conventional way to access it, like there's IHttpContextAccessor for HttpContext.
We have a web app that is a client to our api. The reason I want to do this is because I want to automatically add errors to the web app's ModelState from a DelegatingHandler used by our API client (a typed http client). The handler would watch every response from the API and, for the ones applicable (400 responses with custom error codes in the body, like "Name already taken"), add a message to the ModelState.
So far I've tried asking for a ControllerContext, but it seems to be always null.
var controllerContext = _serviceProvider.GetService<ControllerContext>();
controllerContext?.ModelState.AddModelError("", result.ErrorMessage);
I've also looked at all the registered services using the VS debugger, but I couldn't find anything promising.
Side note (quite a big one) regarding comments about SRP and separation of concerns: I don't think this violates SRP. The API client is a generic client implementation of our API, which can be consumed from anywhere (we currently use it on Xamarin and an ASP.NET Core MVC Web app - the one mentioned in this very question). However, the API client expects a HttpClient in its constructor, which means that its behavior can be modified by its consumers.
The Web App, for example, uses DI to provide the HttpClient the API client needs. That HttpClient is setup to use two delegating handlers, one of which is the one I've described in this question.
As to whether or not ModelState should be manipulated outside of controllers: well, that is exactly what libraries like FluentValidation (and ASP.NET default validation) does.
As to whether or not ModelState should be manipulated in a DelegatingHandler: I think this is a somewhat more valid discussion. However, no one has really presented no argument as to why this is bad.
As to wether or not this should be done "automatically": I think it's better having the code in one place than having to remember to do this every time in every action in every call to the api.
As to whether or not these messages should be even put into the ModelState: well, if I go into that here this side note would become too big. Also, no one has really argued about this, so...
c# asp.net-core httpclientfactory
c# asp.net-core httpclientfactory
asked Jan 2 at 14:27
andre_ss6andre_ss6
69511123
asked Jan 2 at 14:27
andre_ss6andre_ss6
69511123
edited Jan 2 at 17:18
andre_ss6
asked Jan 2 at 14:27
andre_ss6andre_ss6
69511123
asked Jan 2 at 14:27
andre_ss6andre_ss6
69511123
asked Jan 2 at 14:27
andre_ss6andre_ss6
69511123
69511123
why are you not using ActionFilterAttribute instead of DelegatingHandler ?
– Manoj Choudhari
Jan 2 at 14:44
add a comment |
why are you not using ActionFilterAttribute instead of DelegatingHandler ?
– Manoj Choudhari
Jan 2 at 14:44
why are you not using ActionFilterAttribute instead of DelegatingHandler ?
– Manoj Choudhari
Jan 2 at 14:44
why are you not using ActionFilterAttribute instead of DelegatingHandler ?
– Manoj Choudhari
Jan 2 at 14:44
add a comment |
2 Answers
2
active
oldest
votes
You cannot get the ControllerContext itself but what you can get is the ActionContext (which is a more specialized version of the controller context). You can get it by using the IActionContextAccessor:
var actionContextAccessor = _serviceProvider.GetService<IActionContextAccessor>();
var actionContext = actionContextAccessor.ActionContext;
actionContext?.ModelState.AddModelError("", result.ErrorMessage);
You actually don’t need to resolve the action context accessor every time but can keep an instance of it around and just access the action context when you need to. The ActionContext will be set when you are within the scope of an action while handling a request.
An alternative solution would be to separate the concerns and store the errors somewhere else and then populate the model state from there during an action filter. That way, your solution wouldn’t be limited to a MVC way and you could also access those errors elsewhere.
answered Jan 2 at 14:56
pokepoke
216k46336399
That looks promising. I'll take a look after lunch. About your edit on separation of concerns: please refer to my comment on the other answer.
– andre_ss6
Jan 2 at 14:58
@andre_ss6 Although this is a solution but you should not handle model validation in such way. Do it in controller action because model validation should always belongs to controller action. Thank you.
– TanvirArjel
Jan 2 at 15:24
@TanvirArjel I'm not sure if I agree. Both FluentValidation, for example, and even the default ASP.NET implementation validates the model and adds the model state errors in their middleware, before execution reaches the actual action code. The class that does this logic (the one that inherits fromDelegatingHandler) is in the web app project, not the api client. Also, the handler verifies whether or not the context is null before trying to do anything, so that if the api client is used outside of an action context, nothing else happens.
– andre_ss6
Jan 2 at 15:49
@andre_ss6 Yes! You are correct! I also think so but I spoke about custom model validation and adding custom error message that what you have done should be done wither inside controller action or during the model invocation inheritingIValidatableObject.
– TanvirArjel
Jan 2 at 16:58
add a comment |
In my opinion, you would be breaking the single responsibility principle by doing that, since the http client should not know anything about your controllers.
However, if you really want to do it, you can use lambda expressions to pass a reference of the ModelStateDictionary to your delegate, please see: Passing delegate function with extra parameters
If you don't want to break the SRP, one option would be to make the http client return a list of errors to be added by the controller to the modelstate (or null if no errors)
answered Jan 2 at 14:45
Bruno FariasBruno Farias
10919
1
Yea, I don't think I'm violating the SRP. The api client is a library of its own. However, since it uses the new "typed http client" convention brought byIHttpClientFactory(which is justHttpClientDI with some extension methods to help), there are extension points which you can use to alter the api client behavior. Wrapping it up: the client is its own library, with only general api client logic. The delegating handler, however, is in the web app project, and extends the client's functionality.
– andre_ss6
Jan 2 at 14:56
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%2f54008087%2fget-modelstate-outside-of-controller-and-actionfilter%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
You cannot get the ControllerContext itself but what you can get is the ActionContext (which is a more specialized version of the controller context). You can get it by using the IActionContextAccessor:
var actionContextAccessor = _serviceProvider.GetService<IActionContextAccessor>();
var actionContext = actionContextAccessor.ActionContext;
actionContext?.ModelState.AddModelError("", result.ErrorMessage);
You actually don’t need to resolve the action context accessor every time but can keep an instance of it around and just access the action context when you need to. The ActionContext will be set when you are within the scope of an action while handling a request.
An alternative solution would be to separate the concerns and store the errors somewhere else and then populate the model state from there during an action filter. That way, your solution wouldn’t be limited to a MVC way and you could also access those errors elsewhere.
answered Jan 2 at 14:56
pokepoke
216k46336399
That looks promising. I'll take a look after lunch. About your edit on separation of concerns: please refer to my comment on the other answer.
– andre_ss6
Jan 2 at 14:58
@andre_ss6 Although this is a solution but you should not handle model validation in such way. Do it in controller action because model validation should always belongs to controller action. Thank you.
– TanvirArjel
Jan 2 at 15:24
@TanvirArjel I'm not sure if I agree. Both FluentValidation, for example, and even the default ASP.NET implementation validates the model and adds the model state errors in their middleware, before execution reaches the actual action code. The class that does this logic (the one that inherits fromDelegatingHandler) is in the web app project, not the api client. Also, the handler verifies whether or not the context is null before trying to do anything, so that if the api client is used outside of an action context, nothing else happens.
– andre_ss6
Jan 2 at 15:49
@andre_ss6 Yes! You are correct! I also think so but I spoke about custom model validation and adding custom error message that what you have done should be done wither inside controller action or during the model invocation inheritingIValidatableObject.
– TanvirArjel
Jan 2 at 16:58
add a comment |
You cannot get the ControllerContext itself but what you can get is the ActionContext (which is a more specialized version of the controller context). You can get it by using the IActionContextAccessor:
var actionContextAccessor = _serviceProvider.GetService<IActionContextAccessor>();
var actionContext = actionContextAccessor.ActionContext;
actionContext?.ModelState.AddModelError("", result.ErrorMessage);
You actually don’t need to resolve the action context accessor every time but can keep an instance of it around and just access the action context when you need to. The ActionContext will be set when you are within the scope of an action while handling a request.
An alternative solution would be to separate the concerns and store the errors somewhere else and then populate the model state from there during an action filter. That way, your solution wouldn’t be limited to a MVC way and you could also access those errors elsewhere.
answered Jan 2 at 14:56
pokepoke
216k46336399
That looks promising. I'll take a look after lunch. About your edit on separation of concerns: please refer to my comment on the other answer.
– andre_ss6
Jan 2 at 14:58
@andre_ss6 Although this is a solution but you should not handle model validation in such way. Do it in controller action because model validation should always belongs to controller action. Thank you.
– TanvirArjel
Jan 2 at 15:24
@TanvirArjel I'm not sure if I agree. Both FluentValidation, for example, and even the default ASP.NET implementation validates the model and adds the model state errors in their middleware, before execution reaches the actual action code. The class that does this logic (the one that inherits fromDelegatingHandler) is in the web app project, not the api client. Also, the handler verifies whether or not the context is null before trying to do anything, so that if the api client is used outside of an action context, nothing else happens.
– andre_ss6
Jan 2 at 15:49
@andre_ss6 Yes! You are correct! I also think so but I spoke about custom model validation and adding custom error message that what you have done should be done wither inside controller action or during the model invocation inheritingIValidatableObject.
– TanvirArjel
Jan 2 at 16:58
add a comment |
You cannot get the ControllerContext itself but what you can get is the ActionContext (which is a more specialized version of the controller context). You can get it by using the IActionContextAccessor:
var actionContextAccessor = _serviceProvider.GetService<IActionContextAccessor>();
var actionContext = actionContextAccessor.ActionContext;
actionContext?.ModelState.AddModelError("", result.ErrorMessage);
You actually don’t need to resolve the action context accessor every time but can keep an instance of it around and just access the action context when you need to. The ActionContext will be set when you are within the scope of an action while handling a request.
An alternative solution would be to separate the concerns and store the errors somewhere else and then populate the model state from there during an action filter. That way, your solution wouldn’t be limited to a MVC way and you could also access those errors elsewhere.
answered Jan 2 at 14:56
pokepoke
216k46336399
You cannot get the ControllerContext itself but what you can get is the ActionContext (which is a more specialized version of the controller context). You can get it by using the IActionContextAccessor:
var actionContextAccessor = _serviceProvider.GetService<IActionContextAccessor>();
var actionContext = actionContextAccessor.ActionContext;
actionContext?.ModelState.AddModelError("", result.ErrorMessage);
You actually don’t need to resolve the action context accessor every time but can keep an instance of it around and just access the action context when you need to. The ActionContext will be set when you are within the scope of an action while handling a request.
An alternative solution would be to separate the concerns and store the errors somewhere else and then populate the model state from there during an action filter. That way, your solution wouldn’t be limited to a MVC way and you could also access those errors elsewhere.
answered Jan 2 at 14:56
pokepoke
216k46336399
answered Jan 2 at 14:56
pokepoke
216k46336399
answered Jan 2 at 14:56
pokepoke
216k46336399
answered Jan 2 at 14:56
pokepoke
216k46336399
216k46336399
That looks promising. I'll take a look after lunch. About your edit on separation of concerns: please refer to my comment on the other answer.
– andre_ss6
Jan 2 at 14:58
@andre_ss6 Although this is a solution but you should not handle model validation in such way. Do it in controller action because model validation should always belongs to controller action. Thank you.
– TanvirArjel
Jan 2 at 15:24
@TanvirArjel I'm not sure if I agree. Both FluentValidation, for example, and even the default ASP.NET implementation validates the model and adds the model state errors in their middleware, before execution reaches the actual action code. The class that does this logic (the one that inherits fromDelegatingHandler) is in the web app project, not the api client. Also, the handler verifies whether or not the context is null before trying to do anything, so that if the api client is used outside of an action context, nothing else happens.
– andre_ss6
Jan 2 at 15:49
@andre_ss6 Yes! You are correct! I also think so but I spoke about custom model validation and adding custom error message that what you have done should be done wither inside controller action or during the model invocation inheritingIValidatableObject.
– TanvirArjel
Jan 2 at 16:58
add a comment |
That looks promising. I'll take a look after lunch. About your edit on separation of concerns: please refer to my comment on the other answer.
– andre_ss6
Jan 2 at 14:58
@andre_ss6 Although this is a solution but you should not handle model validation in such way. Do it in controller action because model validation should always belongs to controller action. Thank you.
– TanvirArjel
Jan 2 at 15:24
@TanvirArjel I'm not sure if I agree. Both FluentValidation, for example, and even the default ASP.NET implementation validates the model and adds the model state errors in their middleware, before execution reaches the actual action code. The class that does this logic (the one that inherits fromDelegatingHandler) is in the web app project, not the api client. Also, the handler verifies whether or not the context is null before trying to do anything, so that if the api client is used outside of an action context, nothing else happens.
– andre_ss6
Jan 2 at 15:49
@andre_ss6 Yes! You are correct! I also think so but I spoke about custom model validation and adding custom error message that what you have done should be done wither inside controller action or during the model invocation inheritingIValidatableObject.
– TanvirArjel
Jan 2 at 16:58
That looks promising. I'll take a look after lunch. About your edit on separation of concerns: please refer to my comment on the other answer.
– andre_ss6
Jan 2 at 14:58
That looks promising. I'll take a look after lunch. About your edit on separation of concerns: please refer to my comment on the other answer.
– andre_ss6
Jan 2 at 14:58
@andre_ss6 Although this is a solution but you should not handle model validation in such way. Do it in controller action because model validation should always belongs to controller action. Thank you.
– TanvirArjel
Jan 2 at 15:24
@andre_ss6 Although this is a solution but you should not handle model validation in such way. Do it in controller action because model validation should always belongs to controller action. Thank you.
– TanvirArjel
Jan 2 at 15:24
@TanvirArjel I'm not sure if I agree. Both FluentValidation, for example, and even the default ASP.NET implementation validates the model and adds the model state errors in their middleware, before execution reaches the actual action code. The class that does this logic (the one that inherits from
DelegatingHandler) is in the web app project, not the api client. Also, the handler verifies whether or not the context is null before trying to do anything, so that if the api client is used outside of an action context, nothing else happens.– andre_ss6
Jan 2 at 15:49
@TanvirArjel I'm not sure if I agree. Both FluentValidation, for example, and even the default ASP.NET implementation validates the model and adds the model state errors in their middleware, before execution reaches the actual action code. The class that does this logic (the one that inherits from
DelegatingHandler) is in the web app project, not the api client. Also, the handler verifies whether or not the context is null before trying to do anything, so that if the api client is used outside of an action context, nothing else happens.– andre_ss6
Jan 2 at 15:49
@andre_ss6 Yes! You are correct! I also think so but I spoke about custom model validation and adding custom error message that what you have done should be done wither inside controller action or during the model invocation inheriting
IValidatableObject.– TanvirArjel
Jan 2 at 16:58
@andre_ss6 Yes! You are correct! I also think so but I spoke about custom model validation and adding custom error message that what you have done should be done wither inside controller action or during the model invocation inheriting
IValidatableObject.– TanvirArjel
Jan 2 at 16:58
add a comment |
In my opinion, you would be breaking the single responsibility principle by doing that, since the http client should not know anything about your controllers.
However, if you really want to do it, you can use lambda expressions to pass a reference of the ModelStateDictionary to your delegate, please see: Passing delegate function with extra parameters
If you don't want to break the SRP, one option would be to make the http client return a list of errors to be added by the controller to the modelstate (or null if no errors)
answered Jan 2 at 14:45
Bruno FariasBruno Farias
10919
1
Yea, I don't think I'm violating the SRP. The api client is a library of its own. However, since it uses the new "typed http client" convention brought byIHttpClientFactory(which is justHttpClientDI with some extension methods to help), there are extension points which you can use to alter the api client behavior. Wrapping it up: the client is its own library, with only general api client logic. The delegating handler, however, is in the web app project, and extends the client's functionality.
– andre_ss6
Jan 2 at 14:56
add a comment |
In my opinion, you would be breaking the single responsibility principle by doing that, since the http client should not know anything about your controllers.
However, if you really want to do it, you can use lambda expressions to pass a reference of the ModelStateDictionary to your delegate, please see: Passing delegate function with extra parameters
If you don't want to break the SRP, one option would be to make the http client return a list of errors to be added by the controller to the modelstate (or null if no errors)
answered Jan 2 at 14:45
Bruno FariasBruno Farias
10919
1
Yea, I don't think I'm violating the SRP. The api client is a library of its own. However, since it uses the new "typed http client" convention brought byIHttpClientFactory(which is justHttpClientDI with some extension methods to help), there are extension points which you can use to alter the api client behavior. Wrapping it up: the client is its own library, with only general api client logic. The delegating handler, however, is in the web app project, and extends the client's functionality.
– andre_ss6
Jan 2 at 14:56
add a comment |
In my opinion, you would be breaking the single responsibility principle by doing that, since the http client should not know anything about your controllers.
However, if you really want to do it, you can use lambda expressions to pass a reference of the ModelStateDictionary to your delegate, please see: Passing delegate function with extra parameters
If you don't want to break the SRP, one option would be to make the http client return a list of errors to be added by the controller to the modelstate (or null if no errors)
answered Jan 2 at 14:45
Bruno FariasBruno Farias
10919
In my opinion, you would be breaking the single responsibility principle by doing that, since the http client should not know anything about your controllers.
However, if you really want to do it, you can use lambda expressions to pass a reference of the ModelStateDictionary to your delegate, please see: Passing delegate function with extra parameters
If you don't want to break the SRP, one option would be to make the http client return a list of errors to be added by the controller to the modelstate (or null if no errors)
answered Jan 2 at 14:45
Bruno FariasBruno Farias
10919
answered Jan 2 at 14:45
Bruno FariasBruno Farias
10919
answered Jan 2 at 14:45
Bruno FariasBruno Farias
10919
answered Jan 2 at 14:45
Bruno FariasBruno Farias
10919
10919
1
Yea, I don't think I'm violating the SRP. The api client is a library of its own. However, since it uses the new "typed http client" convention brought byIHttpClientFactory(which is justHttpClientDI with some extension methods to help), there are extension points which you can use to alter the api client behavior. Wrapping it up: the client is its own library, with only general api client logic. The delegating handler, however, is in the web app project, and extends the client's functionality.
– andre_ss6
Jan 2 at 14:56
add a comment |
1
Yea, I don't think I'm violating the SRP. The api client is a library of its own. However, since it uses the new "typed http client" convention brought byIHttpClientFactory(which is justHttpClientDI with some extension methods to help), there are extension points which you can use to alter the api client behavior. Wrapping it up: the client is its own library, with only general api client logic. The delegating handler, however, is in the web app project, and extends the client's functionality.
– andre_ss6
Jan 2 at 14:56
1
1
Yea, I don't think I'm violating the SRP. The api client is a library of its own. However, since it uses the new "typed http client" convention brought by
IHttpClientFactory (which is just HttpClient DI with some extension methods to help), there are extension points which you can use to alter the api client behavior. Wrapping it up: the client is its own library, with only general api client logic. The delegating handler, however, is in the web app project, and extends the client's functionality.– andre_ss6
Jan 2 at 14:56
Yea, I don't think I'm violating the SRP. The api client is a library of its own. However, since it uses the new "typed http client" convention brought by
IHttpClientFactory (which is just HttpClient DI with some extension methods to help), there are extension points which you can use to alter the api client behavior. Wrapping it up: the client is its own library, with only general api client logic. The delegating handler, however, is in the web app project, and extends the client's functionality.– andre_ss6
Jan 2 at 14:56
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.
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%2f54008087%2fget-modelstate-outside-of-controller-and-actionfilter%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
why are you not using ActionFilterAttribute instead of DelegatingHandler ?
– Manoj Choudhari
Jan 2 at 14:44