Reputation: 16330
I'm migrating my ASP.Net app to ASP.Net core and one feature that I have is that all my controllers inherit from a base controller in which I do:
protected override void Initialize(HttpControllerContext controllerContext)
{
base.Initialize(controllerContext);
string token = controllerContext.Request.Properties["token"] as string;
user = UserCache.Get(token);
//Called by derived controllers
//to set their repository user
SetInfo();
}
Do I need to move the above code to middleware? Will the middleware allow me to set call the controllers' SetInfo() method?
Upvotes: 5
Views: 3660
Reputation: 882
I had a similar problem when migrating to ASP.NET core. Overriding controller method OnActionExecuting like so
/// <summary>
/// Called before the action method is invoked.
/// </summary>
/// <param name="context">The action executing context.</param>
[NonAction]
public override void OnActionExecuting(ActionExecutingContext context)
{
base.OnActionExecuting(context);
// Do your stuff
}
did it for me. OnActionExecuting is called before the controller method is invoked. This seems to come closest to former Initialize method.
Upvotes: 0
Reputation: 2743
In the first part, it looks like you are extracting a token for authentication purpose. A middleware could be configured to run before your controller action, but it's a matter of how to pass information to your controller. For instance an authentication middleware would simply set the Principal of your HttpRequest that could then be reused during your controller execution.
Regarding the SetInfo, if clearly depends on the nature of the information whether it's a good idea or not to use a middleware to do it, but it's doable. For instance, in my case, for debugging reason in dev, I have a middleware transmitting the information of when will my session expires to my controller by adding it in the HttpContext. I'm not saying it's a good practice though.
context.Request.HttpContext.Items.Add(ExpiresUTCEntry, context.Properties.ExpiresUtc);
Upvotes: 1
Reputation: 11661
Why not turn it into a lazy controller property?
Its nice because now you don't get the user out of the cache if you are not using it.
private User _user;
public User user { get { return _user ?? (_user = UserCache.Get(this.Request.Properties["token"])); } }
About SetInfo()
.
I Suggest to move this code to the constructor or somewhere else (depending on the contents of this function). The Controller is created after the Router
has done its work. By the IControllerFactory
. You can extend the DefaultControllerFactory. This class is responsible for creating controller instances. (make sure to register it in IServiceCollection
, otherwise your class is not the one that is resolved.
In your case i think its best to rethink your architecture here and focus on being as stateless as possible and not using one of the anti-patterns described below.
This is how the request pipeline works in mvc (and still works in aspnetCore).
image from dotnetCurry
If you want to access the user somehwere earlier in the request pipeline, i would suggest:
Upvotes: 0