My First Impression of Profile Providers

I’ve been poking around profile providers for several days now trying to understand one simple thing: besides hard coding profile properties by hand, is there an API for creating properties programmatically?

For example, in Active Directory (AD) you can create user account properties of virtually any kind. In this sense, AD offers you the ultimate flexibility of what fields (besides the canned ones) constitute an account profile, how they are validated, etc.

As I looked through the list of members I’d need to implement for a custom profile provider in ASP.NET 2.0, I only saw GetPropertyValues, SetPropertyValues, and such, but no CreateProperty of a kind. Which is a bummer.

The way I see it, profiles in ASP.NET 2.0 are static. You enter profile properties by hand and get IntelliSense as a convenience feature. This leaves no room for expanding profiles the way you do in Active Directory. I’m sure there are other third-party products of the likes of Active Directory fine-tuned for ASP.NET, but I’d be concerned about their cost and performance. Being able to define properties on the fly with the profile API would be fantastic!

One can argue it’s feasible to write a custom profile provider, but neither this nor this can be called elegant. This is simply a mapper (or adapter, depending on how you look at it) of hand-coded profile properties to corresponding fields in your very own database. A mapper beaten with the ugly end of a stick, at that.

Show Me the Money

Most building blocks in .NET work wonderfully for simplified cases, but a slight deviation causes you to write your own lengthy implementations of interfaces. I can see ASP.NET 2.0 profiles work great in situations where user profiles are isolated and known to be carved in stone from the start.

However, how many applications store nothing but user accounts? Any online store, library, community site would tie user accounts to purchases, orders, activity audits, role-based security, and so forth. A completely isolated storage of user profiles is simply impractical.

So far I’m failing to understand the practicality of profiles. IntelliSense and compile-type checking are awesome, but beyond that… where’s the beef?

Would love to hear your thoughts on this.

You add new properties (and even other more complex objects) via the web.config file's Profile section. These will dynamically be compiled into the Profile object for use in code.

Hi,

I agree with your POV. Do you you an update on this. I'm writing a fairly complex system and trying to work out whether to use the Microsoft provided stuff. From what i can see it's gonna perform pretty badly if used as standard. Would love to hear back from you.