When Profile should be used

[cipcip]

By default profile use sql server xpress provider and probabily, caches
stored data when they are requested for the first time,

So the question is: why we should use profile instead of storyng,
retrieving and caching user data manually from a database?

Is it only for an easier approach of state maintenance, or are there
other advantages?

[Teemu Keiski]

Hi,

there are many reasons why profile has got attention.

- Provider model: you can specify yourself how the profile data is stored,
and what format it takes. You can also switch to use another datastore than
SQL Server or completely another than database
- Provider model implementation is hidden behind the API e.g data model
change & data changes do not affect the usage
- You can define in web.config what gets stored in the profile (what is
personalized)
- you can also have anonymous profile, and you can migrate that to "full"
one if user authenticates/registers etc
- you can change the data on the fly (via Profile property on the Page)

--
Teemu Keiski
ASP.NET MVP, AspInsider
Finland, EU
http://blogs.aspadvice.com/joteke
"cipcip" <pa******@tiscali.it> wrote in message
news:11*********************@g10g2000cwb.googlegro ups.com...

By default profile use sql server xpress provider and probabily, caches
stored data when they are requested for the first time,

So the question is: why we should use profile instead of storyng,
retrieving and caching user data manually from a database?

Is it only for an easier approach of state maintenance, or are there
other advantages?

[Chris Fulstow]

One of the main advantages of using .NET profiles is convenience. The
functionality most people need to persist user data is all there for
you, so you don't need to write you own code.

It also makes your code modular and independant of any particular
implementation because you're coding against a standard Profile
Provider interface. If you ever need to change how your profiles work,
or the database type, you just plug in a new provider without having to
change your application code.

Profiles are also very easy to manage through web.config, you simply
add a new property to the <profile> section and it automatically
appears as a strongly-typed property of you Page.Profile object.

HTH,

Chris

[cipcip]

sincerely thanks for your spontaneous support,

but i have another question related:

i usally manage profile variables manually:

for example i replace this: Profile.Context.Add("email", email)

with this one: myProfileClass.setEmail(email)

setEmail is a function that store user email in a provider like profile
do,
i used this class because i discovered profile after i wrote this
class,
so the question is do you think i should rewrite the intere application
with the use of profile or can i continue use my own class for users
variables managment?

[Teemu Keiski]

Hi,

nothing prevents you from continue using the ready-made solution (and
nothing breaks it) if you feel the cost migrating to built-in profile is too
big.

Basically the profile implementation could also be creating a provider,
which would use your current profile implementation under the covers (e.g
abstract away from your current implementation, and take ASP.NET Profile as
a top-levbel to it), but that could be a big job.

--
Teemu Keiski
ASP.NET MVP, AspInsider
Finland, EU
http://blogs.aspadvice.com/joteke
"cipcip" <pa******@tiscali.it> wrote in message
news:11**********************@z34g2000cwc.googlegr oups.com...

sincerely thanks for your spontaneous support,

but i have another question related:

i usally manage profile variables manually:

for example i replace this: Profile.Context.Add("email", email)

with this one: myProfileClass.setEmail(email)

setEmail is a function that store user email in a provider like profile
do,
i used this class because i discovered profile after i wrote this
class,
so the question is do you think i should rewrite the intere application
with the use of profile or can i continue use my own class for users
variables managment?

[Chris Fulstow]

It depends how much effort you think would be involved, and whether it
would be worth it. It's probably not worth rewriting just for the sake
of it, but it might improve the long-term maintainability of your code
if it uses a standard ASP.NET 2.0 profile implementation.

It also depends on whether the built-in ASP.NET 2.0 profile provider
supports everything you're doing currently, or whether there'd be
additional work required building a custom profile provider.

Chris