ASP.NET 2.0 Replacing Profile Provider Model (apparently its garbage)

[Weston Weems]

I've got the need to have user information for logged in user in a
readily avaliable page context (a lot like how Profile is) except not suck.

Before we jump to any conclusions, from what I gathered, the
implementation of the provider model is absolute garbage. While I've
seen microsoft employees make other questionable design decisions, I
cant possibly fathom why a user profile cant be derived as some other
object.




Perfect Example --

CustomProfile : ProfileBase

Custom profile having the ability to maintain its own collections,
contain methods etc.

Then simply writing the provider (which in my opinion should have a
reference to a user key of some sort, and context to pass the profile
object back.

Of course this would have made TOO much sense. Instead we have this
intermediate step of converting everything to essentially a giant key
based multidimensional array... (GetPropertyValues,SetPropertyValues)

So my question/goal is hopefully to have somone prove me wrong. All I
really want is..

A) when inherting profilebase objects in web.config, for the
setPropertyValues and GetPropertyValues to be called on profile modification

B) Override the Profile property alltogether, since it appears to be
completely and utterly fubar'ed

C) Hopefully not require a bazillion lines of code and user setup to use
my "provider".

 

[Guest]

Hi Weston,

See my reply here to find some guidelance:

http://msdn.microsoft.com/newsgroup...pnet&mid=4fb6e192-047a-4f62-99d9-6bba015dce34

Let me know if you need more help

 

[Weston Weems]

Milosz,

While I see where you are going with your example, I dont quite
understand why the provider model doesnt just expect you to set a
ProfileBase derivative based on a key it provides you.

The whole jumping through the hoops of key value pairs. Also, dont quite
understand why adding inherits flag to the profile element in web.config
effectively prevents SettingsPropertyValueCollection from being called.

I really have to say that it would have made a hell of a lot more sense
to have a IProfile object that has some specified props and methods, and
then have something like SetProfile / GetProfile, and implementation of
how you serialize/deserialize etc the object as a whole, is up to you.

Blah. poor design ftw.
Weston

 

[Guest]

Hi again,

And one more thing,

"Blah. poor design ftw".
I suspect they had much better programmers that we are ;-)

Regards

 

[Guest]

Hi Winston,

I understand your reasoning but ASP.NET 2.0 Profile model is more flexible
than just creating a class with some properties and then serializing /
deserializing to a storage. It's been designed to reduce the time that is
necessary to build web apps.

"...While I see where you are going with your example, I dont quite
understand why the provider model doesnt just expect you to set a ProfileBase
derivative based on a key it provides you. …â€

This is because they must have provided base class to use it with prepared
providers and asp.net framework. C# does not fully support multiple
inheritance (only via interfaces) so you’d have to derive from base and
define and implement “IProfile†yourself, or if they implemented for you, how
would they now which property should be serialized by standard provider - hm?
Ok, I know they could use attributes by not standard ones like Serializable
because they have different meaning in this case. Please also note class can
implement many interfaces, so which should be taken as reflected one? In
addition to that, obvious point is Microsoft wanted to provide efficient and
easy way of building applications, even if we both know real life apps are
more complex and it’s highly probable you’re expecting something more
advanced (and you will code it yourself anyway). But there is a chance some
percentage of developers need to define properties in web.config, change
connection string and that’s it, done.

“…The whole jumping through the hoops of key value pairs. Also, dont quite
understand why adding inherits flag to the profile element in web.config
effectively prevents SettingsPropertyValueCollection from being called…“.

That’s the price for web.config nature of profile feature and the fact, you
may still define more properties in web.config. It also would not be possible
for standard providers (such as SqlProfileProvider) to obtain property values
efficiently (without using reflection). Having all values in hash table
requires “only†boxing/unboxing. I know these loops look horrible but as I
said that’s the price.

Best regards

Milosz

 

[Weston Weems]

I wont jump in and say that its the worst thing I've ever seen, after
all, its a fairly complex problem... I've found theres a difference
between engineers, and programmers. Besides the point, I've seen some
ridiculous designs and ridiculous code.

 

[Weston Weems]

Milosz,

I am really not trying to attack Microsoft... just voicing frustrations
with some of their design decisions...

This is because they must have provided base class to use it with prepared
providers and asp.net framework. C# does not fully support multiple
inheritance (only via interfaces) so you’d have to derive from base and
define and implement “IProfile†yourself, or if they implemented for you, how
would they now which property should be serialized by standard provider - hm?
Ok, I know they could use attributes by not standard ones like Serializable
because they have different meaning in this case. Please also note class can
implement many interfaces, so which should be taken as reflected one? In
addition to that, obvious point is Microsoft wanted to provide efficient and
easy way of building applications, even if we both know real life apps are
more complex and it’s highly probable you’re expecting something more
advanced (and you will code it yourself anyway). But there is a chance some
percentage of developers need to define properties in web.config, change
connection string and that’s it, done.

I wasnt referring to multiple inheritance... I was talking about
Provider model design. When I design software I dont typically plan
stuff out in such a way where ultimately you have control of where data
is coming from, and where its being saved to, but make you jump through
hoops with name value pairs. I mean seriously this is the day and age of
OO design, you think we'd be able to get beyond the concept of a
glorified hashmap. If my provider returned objects I'd basically be
doing the equivalent of re-encoding into some serialized format, then
setting the props, then returning back only to have the framework
re-animate the objects. Ehh, lame.

“…The whole jumping through the hoops of key value pairs. Also, dont quite
understand why adding inherits flag to the profile element in web.config
effectively prevents SettingsPropertyValueCollection from being called…“.

That’s the price for web.config nature of profile feature and the fact, you
may still define more properties in web.config. It also would not be possible
for standard providers (such as SqlProfileProvider) to obtain property values
efficiently (without using reflection). Having all values in hash table
requires “only†boxing/unboxing. I know these loops look horrible but as I
said that’s the price.

Actually my point here was that I can inherit="MyProfileBase" in my
provider line and it would do what I expect (checking
Profile.<SomeMyProfileBaseProperty> and its there with appropriate
type... but looking at breakpoints no matter what you do it wont fire
setvalues/getvalues.

Reasoning because your getter/setter properties are literally to set
values manually (eg, public string name{ get{ return this["name"];}}).
If you want code to be reusable and be just a straight up class with
properties and stuff (regardless of applying ProfileAttributes) this
code is more or less useless. Your profile class will not ever be
anything but a pretty front end to a multidimensional string keyed
array. Again, lame.


So come to find out keeping with good development practices and trying
to have a common place to look for customer information (without jumping
through a million hoops) is a lost cause.

In an effort to make everything more usefull out of the box (which I
will DEFINATELY say microsoft improved on here), I think the provider
model IMPLEMENTATION pretty much crippled because it depends on some
strange intermediate format...

Weston

 

[Guest]

Howdy,

Definitely. I didn't say also it the best possible design, but i only showed
to you there are points to consider when implementing such feature. I have
seen many ridiculous apps , codes and designs too (my favourite is app with
pages making around 200-300 separate database roundtrips to collect simple
data for every page request) and this is not the case.

Regards,

Milosz

 

[Guest]

Hi there again,

'In an effort to make everything more usefull out of the box (which I
will DEFINATELY say microsoft improved on here), I think the provider
model IMPLEMENTATION pretty much crippled because it depends on some
strange intermediate format...'

'...Your profile class will not ever be anything but a pretty front end to a
multidimensional string keyed array...'

The last statement is true but the main problem is to provide values for
serialization without knowing the storage schema (that's what i reckon mst
wanted with sqlserverprovider and web.config configuration) as i explained in
my last post. From OOP's point of view it's crap but how would you apprach
the same problem?(configureable in web.config, no coding, few prepared
providers for lazy programets or low requirements, as fast as possible /
comparing to other methods, extendable..., reusable in different asp.net
parts, and what we don't like any lame coder could use it without knowing
much). I definitely agree you can design and implement your own pure
architecture (you can do it anyway) but you'll spend much more time.

'...Actually my point here was that I can inherit="MyProfileBase" in my
provider line and it would do what I expect (checking
Profile.<SomeMyProfileBaseProperty> and its there with appropriate
type... but looking at breakpoints no matter what you do it wont fire
setvalues/getvalues...'

i'm not sure what you mean but in order to make it work you must follow the
same logic in base class:

public class MyProfileBase : System.Web.Profile.ProfileBase
{
public string Foo
{
get
{
return (string) base["myproperty"];
}
set
{
base["myproperty"] = value;
}
}
}

Maybe someone from MST will tak part in discussion? Wang?
--
Milosz

Milosz,

I am really not trying to attack Microsoft... just voicing frustrations
with some of their design decisions...

This is because they must have provided base class to use it with prepared
providers and asp.net framework. C# does not fully support multiple
inheritance (only via interfaces) so you’d have to derive from base and
define and implement “IProfile†yourself, or if they implemented for you, how
would they now which property should be serialized by standard provider - hm?
Ok, I know they could use attributes by not standard ones like Serializable
because they have different meaning in this case. Please also note class can
implement many interfaces, so which should be taken as reflected one? In
addition to that, obvious point is Microsoft wanted to provide efficient and
easy way of building applications, even if we both know real life apps are
more complex and it’s highly probable you’re expecting something more
advanced (and you will code it yourself anyway). But there is a chance some
percentage of developers need to define properties in web.config, change
connection string and that’s it, done.

I wasnt referring to multiple inheritance... I was talking about
Provider model design. When I design software I dont typically plan
stuff out in such a way where ultimately you have control of where data
is coming from, and where its being saved to, but make you jump through
hoops with name value pairs. I mean seriously this is the day and age of
OO design, you think we'd be able to get beyond the concept of a
glorified hashmap. If my provider returned objects I'd basically be
doing the equivalent of re-encoding into some serialized format, then
setting the props, then returning back only to have the framework
re-animate the objects. Ehh, lame.

“…The whole jumping through the hoops of key value pairs. Also, dont quite
understand why adding inherits flag to the profile element in web.config
effectively prevents SettingsPropertyValueCollection from being called…“.

That’s the price for web.config nature of profile feature and the fact, you
may still define more properties in web.config. It also would not be possible
for standard providers (such as SqlProfileProvider) to obtain property values
efficiently (without using reflection). Having all values in hash table
requires “only†boxing/unboxing. I know these loops look horrible but as I
said that’s the price.

Actually my point here was that I can inherit="MyProfileBase" in my
provider line and it would do what I expect (checking
Profile.<SomeMyProfileBaseProperty> and its there with appropriate
type... but looking at breakpoints no matter what you do it wont fire
setvalues/getvalues.

Reasoning because your getter/setter properties are literally to set
values manually (eg, public string name{ get{ return this["name"];}}).
If you want code to be reusable and be just a straight up class with
properties and stuff (regardless of applying ProfileAttributes) this
code is more or less useless. Your profile class will not ever be
anything but a pretty front end to a multidimensional string keyed
array. Again, lame.


So come to find out keeping with good development practices and trying
to have a common place to look for customer information (without jumping
through a million hoops) is a lost cause.

In an effort to make everything more usefull out of the box (which I
will DEFINATELY say microsoft improved on here), I think the provider
model IMPLEMENTATION pretty much crippled because it depends on some
strange intermediate format...

Weston

 

[Weston Weems]

Milosz,

Exactly... I understand WHY it doesnt call the provider methods. Is
there any way I can completely circumvent profile providers, generate a
ProfileCommon class generator to replace the one in vs.net2005?

Thanks for patience =)

Weston

 

[Guest]

Good morning,

That's actually good question. I know page compiler is invloved in building
ProfileCommon class so I suspect it might not be possible. If you really keen
to know, get youself a nice decent disassembler (Reflector for instance) and
investigate i'll try to do some research too.

Have a nice day

--
Milosz

Milosz,

Exactly... I understand WHY it doesnt call the provider methods. Is
there any way I can completely circumvent profile providers, generate a
ProfileCommon class generator to replace the one in vs.net2005?

Thanks for patience =)

Weston

Hi there again,

'In an effort to make everything more usefull out of the box (which I
will DEFINATELY say microsoft improved on here), I think the provider
model IMPLEMENTATION pretty much crippled because it depends on some
strange intermediate format...'

'...Your profile class will not ever be anything but a pretty front end to a
multidimensional string keyed array...'

The last statement is true but the main problem is to provide values for
serialization without knowing the storage schema (that's what i reckon mst
wanted with sqlserverprovider and web.config configuration) as i explained in
my last post. From OOP's point of view it's crap but how would you apprach
the same problem?(configureable in web.config, no coding, few prepared
providers for lazy programets or low requirements, as fast as possible /
comparing to other methods, extendable..., reusable in different asp.net
parts, and what we don't like any lame coder could use it without knowing
much). I definitely agree you can design and implement your own pure
architecture (you can do it anyway) but you'll spend much more time.

'...Actually my point here was that I can inherit="MyProfileBase" in my
provider line and it would do what I expect (checking
Profile.<SomeMyProfileBaseProperty> and its there with appropriate
type... but looking at breakpoints no matter what you do it wont fire
setvalues/getvalues...'

i'm not sure what you mean but in order to make it work you must follow the
same logic in base class:

public class MyProfileBase : System.Web.Profile.ProfileBase
{
public string Foo
{
get
{
return (string) base["myproperty"];
}
set
{
base["myproperty"] = value;
}
}
}

Maybe someone from MST will tak part in discussion? Wang?

 

[Guest]

Hi there,

Have a look at the System.Web.Compilation namespace especially at
System.Web.Compilation.ProfileBuildProvider class.
--
Milosz

Good morning,

That's actually good question. I know page compiler is invloved in building
ProfileCommon class so I suspect it might not be possible. If you really keen
to know, get youself a nice decent disassembler (Reflector for instance) and
investigate i'll try to do some research too.

Have a nice day

--
Milosz

Milosz,

Exactly... I understand WHY it doesnt call the provider methods. Is
there any way I can completely circumvent profile providers, generate a
ProfileCommon class generator to replace the one in vs.net2005?

Thanks for patience =)

Weston

Hi there again,

'In an effort to make everything more usefull out of the box (which I
will DEFINATELY say microsoft improved on here), I think the provider
model IMPLEMENTATION pretty much crippled because it depends on some
strange intermediate format...'

'...Your profile class will not ever be anything but a pretty front end to a
multidimensional string keyed array...'

The last statement is true but the main problem is to provide values for
serialization without knowing the storage schema (that's what i reckon mst
wanted with sqlserverprovider and web.config configuration) as i explained in
my last post. From OOP's point of view it's crap but how would you apprach
the same problem?(configureable in web.config, no coding, few prepared
providers for lazy programets or low requirements, as fast as possible /
comparing to other methods, extendable..., reusable in different asp.net
parts, and what we don't like any lame coder could use it without knowing
much). I definitely agree you can design and implement your own pure
architecture (you can do it anyway) but you'll spend much more time.

'...Actually my point here was that I can inherit="MyProfileBase" in my
provider line and it would do what I expect (checking
Profile.<SomeMyProfileBaseProperty> and its there with appropriate
type... but looking at breakpoints no matter what you do it wont fire
setvalues/getvalues...'

i'm not sure what you mean but in order to make it work you must follow the
same logic in base class:

public class MyProfileBase : System.Web.Profile.ProfileBase
{
public string Foo
{
get
{
return (string) base["myproperty"];
}
set
{
base["myproperty"] = value;
}
}
}

Maybe someone from MST will tak part in discussion? Wang?