Ivan-Mark Debono
Ivan-Mark Debono

Reputation: 16330

How to use middleware to instead of controller initialize?

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

Answers (3)

Jochen
Jochen

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

Daboul
Daboul

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

Joel Harkes
Joel Harkes

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"])); } }

Call initializer on constructor

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.

Information MVC request pipeline

This is how the request pipeline works in mvc (and still works in aspnetCore). enter image description here image from dotnetCurry

Accessing user earlier in the pipeline

If you want to access the user somehwere earlier in the request pipeline, i would suggest:

  • @dabouls answer: Add middle-ware to inject it in Http.Items
  • Create a UserRepository class and register it to request scope in Ioc container. + use the HttpContextAccessor, but accessing HttpContext.Current is generally an anti-pattern and is discouraged.

Upvotes: 0

Related Questions