Question

I’m finding that in the current application I’m working with, I’m retrieving several entities (related to the authenticated users account) in almost every controller. These entities are cached at the orm layer however, it seems that these entities would be a good candidate to load once at authentication time and add a few properties to the applications custom IPrincipal object.

Another option I was thinking of was creating a custom context object (with the users related account objects) and passing it around with the current request.

Benefits / drawbacks to either approach? Is there another way of dealing with commonly used objects like this?

Answer 1

It sounds like you miss the fact that the instance of IPrincipal/IIdentity is recreated upon every request. It is not persisted anywhere if you not persist it in an explicit way.

I don’t think then there’s performance difference between a custom principal class holding the data vs a cached ambient property.

On the other hand, the drawback of a custom authentication classes is that you have to provide a custom authentication module so that these instances are recreated during AuthenticateRequest event in the processing pipeline. In other words, you’d have to replace FormsAuthenticationModule with your own one. This is not difficult but I wouldn’t do this if it is not absolutely necessary.

Note also that some data can be persisted in the UserData section of the forms cookie. This means that you can have it as long as the cookie is valid and create it only once.