OK to use Csla.ApplicationContext.User for other info?

dagware posted on Saturday, August 04, 2007

I love Csla.ApplicationContext.User. It provides a convenient place to store information about the current user, regardless of whether the code is in a Windows app or a Web app. Thanks to suggestions I received in another thread, I'm now using Csla.ApplicationContext.User in by BOs to update my "Updated By" fields before saving to the database. Works great.

My question is, I'd like to put some other fields in my Identity class, and I wanted to know if there are any gotchas in doing this. Specifically, when the user starts up my application -- either the Windows version or the Web version -- they have to make a couple of selections before they can do anything else. That's the business requirements for this project. So it would seem to me that I could put these selections in my Identity class, and have them available to all BOs just like the ID of current user is now.

I guess the reason I'm asking for opinions is, a class called "Identity" perhaps shouldn't be the place to store non-Identity information. Yet it's so convenient...

Thoughts?

Dan

RockfordLhotka replied on Saturday, August 04, 2007

I have created extended Identity objects for several projects. As long as the new properties are providing information about the current user, it is a natural fit.

If you want to store other data that isn't about the user, then I'd suggest Csla.ApplicationContext.ClientContext.

The only issue you'll encounter when creating a custom Identity object, is that you need to cast it to your specific type to get at your custom properties. This can become a PITA over time. So what I typically do is create a Security static class/Module that delegates all calls down:

Public Module Security
  Public Function IsInRole(role As String) As Boolean
    Return Csla.ApplicationContext.User.IsInRole(role)
  End Function

  Public ReadOnly Property Name() As String
    Get
      Return Csla.ApplicationContext.User.Identity.Name
    End Get
  End Property

  Public ReadOnly Property Department() As String
    Get
      Return CType(Csla.ApplicationContext.User.Identity, CustomIdentity).Department
    End Get
  End Property

  ' ...
End Module

This way your app code can just always use the Security class:

  x = Security.Name
  y = Security.Department

Sometimes I call it "Security", other times "CurrentUser" - but you get the idea.

dagware replied on Saturday, August 04, 2007

Thanks for the reply!

So does Csla.ApplicationContext.ClientContext persist in basically the same manner as the User object does? In other words, Web apps get it restored during every trip back to the server, assuming the user is logged in? If so, it makes more sense to me to use this for the selections the user makes, since they aren't really part of the user's identity.

As for the helper static class -- I'm right there with you. I already wrote one <g>.

Dan

dagware replied on Saturday, August 04, 2007

For anyone following along, I discovered that all the properties in ApplicationContext are explained in a nice table in the 2.1 Handbook. Thanks again, Rocky!

Dan

RockfordLhotka replied on Sunday, August 05, 2007

dagware replied on Monday, August 06, 2007

RockfordLhotka:

Keep in mind, however, that ClientContext and GlobalContext DO flow across the network if you have a remote app server, and so you MUST be careful how much stuff you put in them or performance could really suffer!

Excellent point. Thanks!

Dan