在我正在进行的当前项目中,我们使用asp.NET配置文件来存储有关用户的信息,例如他们在邮件列表中的内容。
现在,为了获得邮件列表中所有用户的列表,我不能简单地进行数据库查询,因为asp.NET配置文件表简单地说,非常糟糕。
对于那些不知道的人,配置文件表有两个主要列,“键”列和“值”列,它们按如下方式组织:
键: Key1:dataType:startIndex:endIndex:key2:dataType。 。等
值: value1value2value3 ...
使用SQL查询几乎是不可能的,因此找到具有特定属性的用户的唯一选择是加载所有用户的列表并循环遍历它。
在一个拥有超过15万名会员的网站中,这是可以理解的非常慢!
有没有具体的理由说明为什么配置文件是这样设计的,还是仅仅是一种动态生成数据的可怕方式?
答案 0 :(得分:5)
我同意这是存储配置文件数据的一种非常糟糕的方式,但我怀疑用例只是为了获得具有单个查询的用户的配置文件数据,但是这样可以扩展它以处理任何数字不同的配置文件属性。如果您不喜欢它,您可以随时编写自己的自定义profile provider,将每个值分隔到自己的列中。在实施了各种会员和角色提供者之后,我认为这不会是一项过于复杂的任务。方法的数量看起来不是太大。
答案 1 :(得分:3)
Provider模型的重点是它抽象出数据源。我们的想法是,作为开发人员,您不需要知道数据的存储方式或格式 - 您只需要一组通用的方法来访问它。这意味着您可以在不更改单行代码的情况下交换提供程序。这也意味着你特意不通过绕过提供者方法直接尝试从数据源直接访问数据(例如直接进入数据库) - 这会使整个点失败。
默认的ASP.NET配置文件提供程序实际上非常功能强大,因为它不仅可以存储简单的值类型(字符串,整数等),还可以存储复杂对象和整个集合。单场。尝试在关系数据库中执行此操作!然而,这种泛型主义的缺点是它以效率为代价。这就是为什么,如果您有特定需求,那么您应该实施自己的提供商。例如,请参阅SearchableSqlProfileProvider - The Searchable SQL Profile Provider。
当然,您的第三个选择是简单地不使用配置文件提供程序 - 没有人强迫您使用!您可以完全实现自己的类/数据库,就像在其他框架中一样。
答案 2 :(得分:1)
我已经实现了各种自定义提供程序(成员资格/站点地图/角色等),并且在看到这种事物(名称/值对或XML数据)之后还没有真正查看过ASP.NET配置文件提供程序。我不确定,但我认为配置文件是主要为用户首选项/设置创建的,其中只有特定用户需要设置,我不认为配置文件是针对可以查询的用户“数据”?
注意:这是基于我认为我知道的一个假设,请另外发表评论。