内置用户配置文件与旧式用户类/表的ASP.NET

内置用户配置文件与旧式用户类/表的ASP.NET

ASP.NET built in user profile vs. old style user class/tables

我正在寻找有关在ASP.NET中使用配置文件功能的最佳实践的指南。

您如何确定应将哪些内容保留在内置用户配置文件中,还是应该创建自己的数据库表并为所需字段添加一列? 例如,一个用户有一个邮政编码,我应该将该邮政编码保存在自己的表中,还是应该将其添加到web.config xml配置文件中并通过用户配置文件ASP.NET机制进行访问?

我现在能想到的优点/缺点是,由于我不太了解配置文件(现在有点矩阵),所以如果我走桌子路线,我可能会做我想做的任何事情(例如, SQL,以使所有用户使用与当前用户相同的邮政编码。 我不知道是否可以使用ASP.NET配置文件执行相同的操作。


香港专业教育学院仅建立了2个使用配置文件提供程序的应用程序。从那时起,我一直远离使用它。对于这两个应用程序,我都使用它来存储有关用户的信息,例如他们的公司名称,地址和电话号码。

在我们的客户希望能够通过这些字段之一找到用户之前,此方法一直很好。
搜索涉及遍历每个用户配置文件并将信息与搜索条件进行比较。随着用户群的增长,我们的客户无法接受搜索时间。唯一的解决方案是创建一个表来存储用户信息。搜索速度大大提高。

我建议将这种类型的信息存储在自己的表中。


用户个人资料是用于个人定制的很好的简洁框架(AKA。个人资料属性)。 (例如iGoogle)
它的问题是它不是为查询而设计的,也不是与公共用户共享数据的理想选择。(您仍然可以这样做,但性能低下)

因此,如果您想增强自定义的用户体验,则最好使用用户个人资料。否则,使用您自己的类和表将是更好的解决方案。


我认为最好将它用于对用户而言并不重要的补充数据,而补充数据通常仅在该用户无论如何登录时才重要。考虑一下如果擦除了所有不会破坏任何重要数据的数据。

当然,这是个人喜好,但其他人提出了其他一些重要问题。

考虑到可以将其用于使用匿名Cookie维护其个人资料的未经身份验证的用户,它也非常有用。


我认为这取决于您需要多少个领域。据我所知,概要文件本质上是一个长字符串,会按照给定的字段大小进行拆分,这意味着如果您有许多字段和用户,它们的伸缩性将不会很好。

另一方面,它们是内置的,因此这是一种简单且标准化的方式,这意味着学习曲线不会很大,您也可以在将来的应用程序中使用它,而无需将其调整为新的表结构。

滚动自己的东西可以将其放入适当规范的数据库中,这可以大大提高性能,但是您几乎必须自己编写所有概要文件管理代码。

编辑:此外,不会缓存配置文件,因此对配置文件的每次访问都会首先进入数据库(然后针对该请求进行缓存,但是下一个请求将再次从数据库获取它)。

如果您正在考虑编写自己的东西,也许定制的Profile Provider可以为您提供两全其美的体验-无缝集成,但是您想要做的定制东西。


以我的经验,最好将配置文件中的信息保持在最低限度,仅将身份验证直接需要的要点放在其中。其他信息(例如地址)应通过自己的应用程序逻辑保存在自己的数据库中,这种方法更具扩展性和可维护性。


推荐阅读