我正在寻找有关在 ASP.NET 中使用 Profile 功能的最佳实践的指导。
您如何决定应该在内置用户配置文件中保留什么，或者是否应该创建自己的数据库表并为所需字段添加一列？例如，一个用户有一个邮政编码，我应该将邮政编码保存在自己的表中，还是应该将其添加到 web.config xml 配置文件并通过用户配置文件 ASP.NET 机制访问它？
我现在能想到的优点/缺点是，由于我不太了解个人资料（现在有点像矩阵），如果我走桌子路线，我可能可以做任何我想做的事情（例如， SQL 以获取与当前用户相同的邮政编码中的所有用户）。如果我使用 ASP.NET 配置文件，我不知道是否可以这样做。
我只构建了 2 个使用配置文件提供程序的应用程序。从那以后我就不再使用它了。对于这两个应用程序，我使用它来存储有关用户的信息，例如他们的公司名称、地址和电话号码。
这一直很好，直到我们的客户希望能够通过这些字段之一找到用户。搜索涉及遍历每个用户配置文件并将信息与搜索条件进行比较。随着用户群的增长，我们的客户无法接受搜索时间。唯一的解决方案是创建一个表来存储用户信息。搜索速度大大提高。
我建议将此类信息存储在其自己的表中。
用户配置文件是用于个人定制（AKA。配置文件属性）的一个很好的干净框架。（例如 iGoogle）它的问题是它不是为查询而设计的，也不适合与公共用户共享数据。（你仍然可以做到，但性能低下）
因此，如果您想增强定制的用户体验，用户配置文件将是一个不错的选择。否则，使用您自己的类和表将是一个更好的解决方案。
根据我的经验，最好将配置文件中的信息保持在最低限度，只将身份验证直接需要的必需品放入其中。地址等其他信息应该由你自己的应用程序逻辑保存在你自己的数据库中，这种方式更具可扩展性和可维护性。
我认为这取决于您需要多少个字段。据我所知，Profiles 本质上是一个长字符串，会在给定的字段大小处拆分，这意味着如果您有很多字段和用户，它们的扩展性不会很好。
另一方面，它们是内置的，因此这是一种简单且标准化的方式，这意味着学习曲线并不大，您也可以在未来的应用程序中使用它，而无需将其调整为新的表格结构。
滚动你自己的东西可以让你把它放在一个适当规范化的数据库中，这极大地提高了性能，但是你必须自己编写几乎所有的配置文件管理代码。
编辑：此外，配置文件没有被缓存，因此对配置文件的每次访问都会首先进入数据库（然后为该请求缓存它，但下一个请求将再次从数据库中获取它）
如果您正在考虑编写自己的东西，也许自定义 Profile Provider可以为您提供两全其美的优势 - 无缝集成，以及您想要做的自定义内容。
我认为最好将其用于对用户来说并不重要的补充数据，这些数据通常仅在该用户登录时才重要。想想如果全部擦除不会破坏任何重要的数据。
当然这是个人偏好，但其他人提出了其他一些重要问题。
考虑到它可以用于未经身份验证的用户，其个人资料由匿名 cookie 维护，也非常有用。