C# 为什么asp.NET概要文件设计得如此糟糕？

在我正在进行的当前项目中，我们使用asp.NET配置文件来存储有关用户的信息，例如他们在邮件列表中的参与情况

现在，为了获得邮件列表中所有用户的列表，我不能简单地进行数据库查询，因为简单地说，asp.NET概要文件表非常糟糕

对于那些不知道的人，配置文件表有两个主要列，“键”列和“值”列，它们的组织方式如下：

关键点： Key1:dataType:startIndex:endIndex:key2:dataType。等等

价值观： 值1值2值3

使用SQL进行查询几乎是不可能的，因此查找具有特定属性的用户的唯一选项是加载所有用户的列表并在其中循环

在一个拥有超过15万会员的网站上，这是可以理解的非常缓慢

---

配置文件设计成这样是有具体原因的，还是它只是一种糟糕的动态生成数据的方式？

我已经实现了各种自定义提供程序（成员资格/站点地图/角色等），但在看到此类内容（名称/值对或XML数据）后，还没有真正查看ASP.NET配置文件提供程序。我不确定，但我认为该配置文件主要是为用户首选项/设置创建的，其中设置仅针对特定用户，我不认为该配置文件是为可查询的用户“数据”创建的

---

注意：这是一个基于我认为我知道的情况的假设，请对此进行评论。

我同意这是一种非常糟糕的存储配置文件数据的方法，但我怀疑用例只是通过一个查询为用户获取配置文件数据，但其扩展方式可以处理任意数量的不同配置文件属性。如果您不喜欢它，您可以编写自己的自定义项，将每个值分离到自己的列中。在实现了各种成员资格和角色提供者之后，我认为这不是一项太复杂的任务。方法的数量看起来不太多。

提供者模型的关键在于它将数据源抽象出来。其思想是，作为一名开发人员，您不需要知道数据是如何存储的或以什么格式存储的——您只需要有一组访问数据的通用方法。这意味着您可以在不更改一行代码的情况下交换提供程序。这还意味着您不必通过绕过提供程序方法直接尝试从数据源访问数据（例如直接访问数据库），这会破坏整个要点

默认的ASP.NET概要文件提供程序实际上非常强大，因为它不仅可以存储简单的值类型（字符串、整数等），还可以在单个字段中存储复杂的对象和整个集合。尝试在关系数据库中这样做！然而，这种通用ism的缺点是它以效率为代价。这就是为什么，如果您有特定的需求，那么您应该实现自己的提供者。例如，请参见

---

当然，您的第三个选择是简单地不使用配置文件提供程序-没有人强迫您这么做！您可以完全实现自己的类/数据库，就像在其他框架中一样。

这支持我的“理论”：-，实际上，实现您的配置文件提供程序意味着您可以以不同的方式存储值，但是如果您有自己的成员资格提供程序，我不明白为什么您可以使用它？@Mark-您当然可以重用同一个表，但成员资格提供程序接口不允许您访问任意属性。通常，我只是省略ProfileProvider并滚动我自己的配置文件处理代码，将数据分离到不同的表中--联系人、首选项等等--并根据当前（或选定）用户使用我的数据层访问它们。你说得对。配置文件提供程序不是为大量数据创建的。是的，我同意我经常有一个单独的“用户”类，带有MembershipID属性，它将成员身份id guid绑定到该类。。。我所有的个人资料都在里面。