ASP.NET 2.0替换配置文件提供程序模型（显然它的垃圾） [英] ASP.NET 2.0 Replacing Profile Provider Model (apparently its garbage)
问题描述
我需要在
随时可用的页面上下文中获取登录用户的用户信息（很像Profile的内容），除非不是吮吸。
在我们得出任何结论之前，从我收集的内容来看，提供者模型的实现是绝对垃圾。虽然我已经看到微软员工做出了其他可疑的设计决策，但是我不能理解为什么用户档案不能像其他人一样派生出来。
对象。
完美示例 -
CustomProfile：ProfileBase
自定义配置文件能够维护自己的集合，
包含方法等。
然后简单地写提供者（在我看来应该有一个
引用某种用户键，以及传递配置文件的上下文
对象返回。
当然这会有太有道理了。相反，我们有这个
中间步骤，将所有内容转换为基本上是一个巨大的密钥
基于
的多维数组......（GetPropertyValues，SetPropertyValues）
所以我的问题/目标是希望有人能证明我的错误。我只需要b $ b我想要的是......
A ）当inherting profil web.config中的ebase对象，用于在配置文件修改时调用
setPropertyValues和GetPropertyValues
B）全部覆盖Profile属性，因为它看起来像
完全和完全fubar''ed
C）希望不需要大量的代码和用户设置才能使用
我的提供者。
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".
推荐答案
您好Weston，
请在此处查看我的回复指南：
http://msdn.microsoft.com/newsgroups...9-6bba015dce34
让我知道你是否需要更多帮助
-
Milosz
" Weston Weems"写道：
Hi Weston,
See my reply here to find some guidelance:
http://msdn.microsoft.com/newsgroups...9-6bba015dce34
Let me know if you need more help
--
Milosz
"Weston Weems" wrote:
我需要在
随时可用的页面上下文中获取登录用户的用户信息（很多就像配置文件一样）除了没有糟糕。
在我们得出任何结论之前，从我收集的内容来看，提供者模型的
实现是绝对垃圾。虽然我已经看到微软员工做出了其他可疑的设计决策，但是我不能理解为什么用户档案不能像其他人一样派生出来。
对象。
完美示例 -
CustomProfile：ProfileBase
自定义配置文件能够维护自己的集合，
包含方法等。
然后简单地写提供者（在我看来应该有一个
引用某种用户键，以及传递配置文件的上下文
对象返回。
当然这会有太有道理了。相反，我们有这个
中间步骤，将所有内容转换为基本上是一个巨大的密钥
基于
的多维数组......（GetPropertyValues，SetPropertyValues）
所以我的问题/目标是希望有人能证明我的错误。我只需要b $ b我想要的是......
A ）当加入profilebase o时web.config中的bjects，用于在配置文件修改时调用的
setPropertyValues和GetPropertyValues
B）全部覆盖Profile属性，因为它似乎是
完全和完全fubar''ed
C）希望不需要使用数十亿行代码和用户设置
我的提供者。
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".
Milosz，
虽然我看到你的例子，我不太了解b $ b了解为什么提供者模型不希望你根据它提供给你的密钥设置一个
ProfileBase衍生物。
整个跳过关键值对的箍。另外，没有完全理解为什么在web.config中向profile元素添加继承标志的原因
有效地阻止了调用SettingsPropertyValueCollection。
我真的不得不说，如果有一个具有一些指定道具和方法的IProfile对象，那将会更加有意义
，然后
然后有类似SetProfile / GetProfile的东西，以及
如何序列化/反序列化等整个对象的实现，取决于你。
Blah。糟糕的设计ftw。
Weston
Milosz Skalecki [MCAD]写道：
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
Milosz Skalecki [MCAD] wrote:
Hi Weston，
请在此处查看我的回复以找到一些指南：
http://msdn.microsoft.com/newsgroups...9-6bba015dce34
如果您需要更多帮助请告诉我
Hi Weston,
See my reply here to find some guidelance:
http://msdn.microsoft.com/newsgroups...9-6bba015dce34
Let me know if you need more help
嗨再次，
还有一件事，
" Blah。糟糕的设计ftw"。
我怀疑他们有更好的程序员，我们是;-)
问候
-
Milosz
" Milosz Skalecki [MCAD]"写道：
Hi again,
And one more thing,
"Blah. poor design ftw".
I suspect they had much better programmers that we are ;-)
Regards
--
Milosz
"Milosz Skalecki [MCAD]" wrote:
嗨Winston，
我理解你的推理但ASP.NET 2.0 Profile模型更灵活
，而不仅仅是创建一个具有某些属性的类，然后序列化/
反序列化到存储。它旨在减少构建网络应用程序所需的时间。
" ...虽然我看到你要去的地方以你的例子，我不太明白为什么提供者模型不希望你根据它提供给你的密钥设置一个ProfileBase
衍生物。 a？| a ??
这是因为他们必须提供基类才能将它与准备好的
提供程序和asp.net框架一起使用。 C＃不完全支持多个
继承（只能通过接口）所以你必须从base派生并且
定义并实现一个?? IProfilea ??你自己，或者如果他们为你实现了，他们现在应该如何通过标准提供商序列化哪个属性 - 嗯？
好吧，我知道他们可以使用属性而不是标准的如Serializable
因为它们在这种情况下有不同的含义。还请注意课程可以实现很多接口，所以应该把它作为反映的一个？在
除此之外，显而易见的一点是，微软希望提供高效且简单的构建应用程序的方法，即使我们都知道现实应用程序是
更复杂，而且很可能你会期待更高级的东西（无论如何你会自己编码）。但是有一些机会开发人员需要在web.config中定义属性，更改
连接字符串并且完成它。
a ?? a？|整个跳过关键值对的箍。另外，没有完全理解为什么在web.config中为profile元素添加继承标志的原因
有效地阻止了SettingsPropertyValueCollection被调用？| a ??。
Thata ??是配置文件功能的web.config性质的价格，事实上，你可以在web.config中定义更多属性。标准提供者（例如SqlProfileProvider）也不可能有效地获得属性值
（不使用反射）。将所有值都放在哈希表中
需要一个?? onlya ??装箱/拆箱。我知道这些循环看起来很可怕，但是因为我说b $ b这个价格。
祝你好运
Milosz
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. a?|a??
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 youa??d have to derive from base and
define and implement a??IProfilea?? 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 ita??s highly probable youa??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 thata??s it, done.
a??a?|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 calleda?|a??.
Thata??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 a??onlya?? boxing/unboxing. I know these loops look horrible but as I
said thata??s the price.
Best regards
Milosz
这篇关于ASP.NET 2.0替换配置文件提供程序模型（显然它的垃圾）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
