是否使用 ASP.NET 配置文件？答案

【问题标题】：Use ASP.NET Profile or not?是否使用 ASP.NET 配置文件？
【发布时间】：2011-02-19 17:53:24
【问题描述】：

我需要存储经过身份验证的用户的一些属性（我正在使用 Membership API），并且我需要在使用 Profiles 或添加一个以 UserId 作为 PK 的新表之间做出选择。使用配置文件似乎很快，并且需要较少的前期工作。但是，我看到以下缺点：

配置文件值被压缩到单个 ntext 列中。在将来的某个时候，我将拥有可以更新用户属性的 SQL 脚本。查询一个 ntext 列并尝试更新一个值对我来说听起来有点麻烦。
如果我选择添加新的用户特定属性并希望为所有现有用户分配默认值，是否可以？

我的第一印象是，从长远来看，使用配置文件可能会导致维护问题。想法？

【问题讨论】：

+1 - 更好的问题。表明您已亲自检查过问题但仍有疑问的主动性。
我想出了一种查询默认配置文件提供程序数据的方法，对我来说效果很好：stackoverflow.com/a/13747590/64334

标签： asp.net asp.net-membership

【解决方案1】：

在 MSDN（现在在 ASP.NET http://www.asp.net/downloads/sandbox/table-profile-provider-samples）上有一篇文章讨论了如何制作 Profile Table Provider。这个想法是将 Profile 数据存储在一个表中而不是一行中，从而更容易使用 SQL 进行查询。

更多关于这一点，SQL Server 2005/2008 支持通过服务和 CLR 代码获取数据。可以想象，您可以通过 API 而不是直接访问基础表来访问 Profile 数据。

至于第 2 点，您可以将默认值设置为属性，虽然这不会立即更新其他配置文件，但配置文件会在下次访问时更新。

【讨论】：

您能否评论一下“Profile Table Provider”对于大型用户群的灵活性和性能？
+1 如果您的个人资料数据和/或访问要求不那么重要，这就是您要走的路。由于默认动态配置文件实现所需的序列化/反序列化，基于表的提供程序的性能要好得多。
@DotNetDude：恐怕这取决于您对大的定义。至于灵活性，通过使用提供程序，开发人员可以继续在代码中使用 Profile API。这使得开发解决方案在一般意义上可以在谷歌上使用（或者 StackOverflow 可以重新搜索，如果你愿意的话），而不是一些自定义的一次性。性能度量还必须考虑问题第 1 点的初衷：让配置文件数据以比标准配置文件数据库模式更易于查询的格式提供。表格提供者在那里获得了一些积分。

【解决方案2】：

在我看来，您已经回答了自己的问题。如果您的第 1 点很可能发生，那么 SQL 表是唯一明智的选择。

【讨论】：

【解决方案3】：

看看这个问题...

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

内置配置文件设计不当的第一个提示是它们在关系数据库中使用分隔数据。在一些情况下，RDBMS 中的分隔数据是有意义的，但这绝对不是其中之一。

除非您有特定原因使用 ASP.Net 配置文件，否则我建议您使用单独的表格。

【讨论】：

设计不好？您将如何设计一个动态配置文件系统，该系统只需修改配置文件即可开箱即用……在 2003 年？我会说有一些非常聪明的人把它放在适当的位置，你的“提示”是错误的。
@code ponet：否决票并不是因为不同意意见:) 我认为将分隔数据放在通用配置文件数据的单个列中是一个糟糕的设计。有一些众所周知的桌子设计可以解决这个概念。
' 如果您看到错误信息，请投反对票。 ' stackoverflow.com/faq - 将 ASP.Net 配置文件简单地描述为设计不良是错误信息，可能会不必要地转移一些经验不足的人，从使用默认提供商提供的非常简单的设施转向不必要的复杂售后市场专业解决方案。同样，您将如何提供相同的功能，即 OOB 能够仅使用配置提供瞬态、动态用户元数据？
我不得不说你的结论也是不好的建议。除非您有特定原因不使用默认提供程序，否则最好不要重新发明轮子。