Universal "Session" Functionality?

[Steve - DND]

I'm currently creating an application with an n-tier design(not separate
boxes for each layer, just separation of pres/logic/data) that will have
both a web and windows interface. I'm trying to find out if there is a way
to maintain user information and access it in either my business logic or
data layer, without having to pass some custom object around that contains
the information.

For the web there's of course the Session, or preferably the
User(implementing IPrincipal), but I can't figure out what there is for a
WinForms app, or just something in general I can access in a class library
that isn't directly tied to either application.

If someone could give me some information on how I can access IPrincipal
information uniformly it would be most appreciated.

Thanks,
Steve

 

[Greg Ewing [MVP]]

Steve, how about creating your own session class and storing the state in a
database? Once you have that you can access it through both the web app and
the WinForm as long as you have access to the DB. You'll pay a performance
penalty for teh flexibility but there are many situations where it is worth
it.

 

[Steve - DND]

That's pretty much what I wanted to avoid. One of the primary reasons for
maintaining this information for the user would be to retain their
connection string, which is set at login. Storing it in the DB would mean
two hits for each DB action. I'm surprised MS didn't implement something
like this for however a .Net application is run.

Steve

 

[Alvin Bruney]

how about a file then, disk or memory file can do. You said you didn't want
to pass objects around but that's the next best thing if you want to avoid
the database hit.

--
Regards,
Alvin Bruney
Got tidbits? Get it here...
http://tinyurl.com/2bz4t

That's pretty much what I wanted to avoid. One of the primary reasons for
maintaining this information for the user would be to retain their
connection string, which is set at login. Storing it in the DB would mean
two hits for each DB action. I'm surprised MS didn't implement something
like this for however a .Net application is run.

Steve

Steve, how about creating your own session class and storing the state

in

 

[Greg Ewing [MVP]]

Steve, are you on an Active Directory domain or have access to an LDAP
server? I've had great success putting user db connection strings in AD.
It's optimized for read so it's very fast. If you have to do a lot of
updates I'd probably go with the DB.

--
Greg Ewing [MVP]
http://www.citidc.com

how about a file then, disk or memory file can do. You said you didn't want
to pass objects around but that's the next best thing if you want to avoid
the database hit.

 

[Steve - DND]

No, I don't at the moment(depending on growth there may be soon though). I'm
not sure how much that would help though. I'm doing SQL Authentication(to
users in in broad groups(end-users, resellers, etc...)), rather than
Windows. So would that mean that I would have to create a new user in AD for
each user of the system? If I did, how would I go about getting the
connection string info without passing data through to all of the necessary
functions? Is the user credential information somehow contained on the
current thread or some such?

Thanks,
Steve

 

[Greg Ewing [MVP]]

Steve, if you are using a Windows app or a web app which requires NT
authentication then yes, it is on the current thread. I don't remember the
properties off the top of my head but look in the System.Security namespace.
There should be properties like CurrentUser, WindowsPrincipal, or something
like that. If your web app uses anonymous access then you will only have
whatever user your WebApp runs under (ASPNET by default).