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.

--
Greg Ewing [MVP]
http://www.citidc.com
"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:un*************@TK2MSFTNGP11.phx.gbl...

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

[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

"Greg Ewing [MVP]" <gewing@_NO_SPAM_gewing.com> wrote in message
news:uY**************@TK2MSFTNGP12.phx.gbl...

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.

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

[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
"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:uF**************@TK2MSFTNGP11.phx.gbl...

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

"Greg Ewing [MVP]" <gewing@_NO_SPAM_gewing.com> wrote in message
news:uY**************@TK2MSFTNGP12.phx.gbl...

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.

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

[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
"Alvin Bruney" <vapor at steaming post office> wrote in message
news:Oq**************@TK2MSFTNGP10.phx.gbl...

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
"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:uF**************@TK2MSFTNGP11.phx.gbl...

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

"Greg Ewing [MVP]" <gewing@_NO_SPAM_gewing.com> wrote in message
news:uY**************@TK2MSFTNGP12.phx.gbl...

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.

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

[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]" <gewing@_NO_SPAM_gewing.com> wrote in message
news:uf**************@TK2MSFTNGP10.phx.gbl...

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
"Alvin Bruney" <vapor at steaming post office> wrote in message
news:Oq**************@TK2MSFTNGP10.phx.gbl...

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
"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:uF**************@TK2MSFTNGP11.phx.gbl...

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

"Greg Ewing [MVP]" <gewing@_NO_SPAM_gewing.com> wrote in message
news:uY**************@TK2MSFTNGP12.phx.gbl...
> 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.
>
> --
> Greg Ewing [MVP]
> http://www.citidc.com

[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).

--
Greg Ewing [MVP]
http://www.citidc.com
"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:OU**************@TK2MSFTNGP10.phx.gbl...

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]" <gewing@_NO_SPAM_gewing.com> wrote in message
news:uf**************@TK2MSFTNGP10.phx.gbl...

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
"Alvin Bruney" <vapor at steaming post office> wrote in message
news:Oq**************@TK2MSFTNGP10.phx.gbl...

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
"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:uF**************@TK2MSFTNGP11.phx.gbl...
> 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
>
> "Greg Ewing [MVP]" <gewing@_NO_SPAM_gewing.com> wrote in message
> news:uY**************@TK2MSFTNGP12.phx.gbl...
> > 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.
> >
> > --
> > Greg Ewing [MVP]
> > http://www.citidc.com
>
>