游民家园

• 我的参与
• 我的新闻
• 最新评论
• 我的标签

评论

#1楼 2007-03-01 10:40 JesseZhao      

我是直接使用的Membership，因为我感觉直接用就ok了，项目比较小，没有那么复杂的逻辑   回复  引用  查看    

#2楼 2007-03-01 10:41 JesseZhao      

方法一感觉不太合适，虽然添加的时候是方便了，可是读取的时候呢，是不是要两次读取，可能还要自己写sql 语才能读出来那个BizUserID啊   回复  引用  查看    

#3楼 2007-03-01 10:43 teana[未注册用户]

实际的项目里暂时还没用到。。基本都是实现一套新的。。   回复  引用    

#4楼 2007-03-01 19:33 Tony.Gong      

一般都是直接写，不直接用   回复  引用  查看    

#5楼 2007-03-01 19:49 xiaozhi[未注册用户]

如果UserID是uniqueindentifier类型的话，相对int类型而言，查询的速度将受到一定程序的影响（注：未测试)

------------------------------------------------------------
记得好像有一本书里提到过，用uniqueindentifier比用identity要好一点

具体好在什么地方？忘了
你可以搜搜   回复  引用    

#6楼 2007-03-01 20:34 无常      

我现在的项目在也遇到这个问题，
我的方法是重写了MembershipProvider，当然也不再用aspnet_*等默认表。
  回复  引用  查看    

#7楼 2007-03-01 21:19 webabcd      

因为不同的application的username可以相同
所以userid是uniqeidentifier类型确保唯一

membership和rolemanager已经把权限这部分封装的很好了，而你的用户的其它信息是不属于权限范畴的，建关联表是最好的做法   回复  引用  查看    

#8楼 2007-03-01 21:56 deerchao      

CommunityServer采用的是第二种.

采用Membership不仅是为了实现方便,更重要的是比较容易与别人开发的程序进行用户共享.   回复  引用  查看    

#9楼 2007-03-01 22:02 TT[未注册用户]

全部重新设计实现,包括Webpart个性化, 用户ID类型不同,而用的是SQL和存储过程,我们用ORM,没法统一.   回复  引用    

#10楼 2007-03-02 08:51 生活、工作      

只能说ASP.NET 2.0内置实现的 SqlMembershipProvider 中，一些地方定义为GuId类型了，就MembershipUser 的 ProviderUserKey而言，是object类型的，想让他是什么类型就是什么类型。你完全可以重写SqlMembershipProvider 将 ProviderUserKey作为int类型

有本书叫：
Programming Microsoft ADO.NET 2.0 - Applications Advanced Topics.chm 其第五章介绍了 Who's Afraid of the Big, Bad GUID?
作者最后的结论是：（这仅仅是作者的结论）

如果使用GUID键实现，则移动数据只是将数据从一个数据库复制到另一个数据库，因此，GUID键是这一比较回合的赢家。
最终的赢家是… 我刚刚开发完成了一项实现GUID键的大型项目，并且还开发了多个使用智能键和Identity键实现的项目。表5.2总结了各种键类型在一些影响性能、数据大小和易用性等因素中所占的百分比。我根据自己使用这些键类型的经验，将权重值的范围设定为0%到100%，其中100%表示权重值最大。此外，键类型的系数分为以下三级：第一级系数为1，第二级系数为0.5，第三级系数为0，通过将键类型系数乘以每个因素的权重值，就可以得到每种键类型的权重值。
表5.2 基于因素及其权重的最终百分比
权重值
因素及其权重 智能键 Identity键 GUID键
数据大小 = 25% 12.5% 25% 0%
键的可见性 = 5% 5% 2.5% 0%
键的易修改性 = 20% 0% 10% 20%
联接个数 = 5% 5% 2.5% 2.5%
SQL复杂性 = 5% 0% 5% 2.5%
确保惟一性 = 25% 0% 12.5% 25%
数据移动 = 15% 7.5% 0% 15%
总计 = 100% 30% 57.5% 65%

根据表5.2中的权重值，GUID键的绝大部分因素权重值都是最大的。如果大家对某些因素的权重存有异议，可以尝试着修改权重以验证是否能得到不同的结果。注意，这些主键的实现都不能面分之百地满足所有因素。一般认为，GUID键实现是最适合非连接数据应用程序的。智能键实现是否有属于自己的用武之地呢？有的，它最适合用于数据仓库应用程序，因为数据仓库应用程序在设计上一般都会提供高性能只读访问，并且包含最少的联接数。因为数据是只读的，所以“修改键”因素所占的权重较小。表5.3通过对表5.2中的权重进行局部调整，提供了各种键类型基于另一种权重的百分比。


第五章 ：
http://www.china-pub.com/computers/ebook25001-30000/28154/ch05.rar">http://www.china-pub.com/computers/ebook25001-30000/28154/ch05.rar   回复  引用  查看    

#11楼 2007-03-02 09:11 第一控制.NET      

昨天刚要回复的时候服务器挂了。

我现在用的是默认membership+自定义profile。感觉大部分问题都能简单解决，而且可以和其他member程序快速整合。   回复  引用  查看    

#12楼 2007-03-02 12:02 天天      

可能第二种情况是比较好的。
TO Tony.Gong :
使用内置的好处是，有许多功能比较方便，例如锁定帐户，用户最后访问日期等都可以通过函数得到，所以用还是好用的。
我目前遇到的问题是内置的功能不够用，例如我获取角色描述信息，以及角色所在的组，竟然没有类似的函数，自定义模型又很麻烦。 这的是鸡肋－－－－要么很简单，要么很困难   回复  引用  查看    

#13楼 2007-03-02 13:53 生活、工作      

XXRoleProvider roleProvider = Roles.Provider as XXRoleProvider;
可以在XXRoleProvider中添加 获取角色描述信息，以及角色所在的组 功能。   回复  引用  查看    

#14楼 2007-03-02 16:16 Cat Chen      

如果你不喜欢SqlMembershipProvider，可以自己写一个新的MembershipProvider。重点在于Provider，而Membership只是调用Provider的抽象。   回复  引用  查看    

#15楼 2007-03-03 11:48 陈工[未注册用户]

Membership相对来说还是比较好用的，按照说明配制成功后，如果感觉它提供的功能不够，自己对系统数据库了解后可以再扩展。
不过只用过一次，而且扩展了。
我本人后来开发的系统都是采用自己的用户系统。   回复  引用    

#16楼 2007-03-03 16:42 维生素C.NET      

重写，取舍，赞成Cat Chen   回复  引用  查看    

#17楼 2007-03-03 16:43 维生素C.NET      

更重要的是看情况而定，怎么容易实现怎么来，不行的时候在重写或选用其他方案。   回复  引用  查看    

#18楼 2007-03-06 14:29 MS的明天      

各有利弊。   回复  引用  查看    

#19楼 2007-04-04 14:52 heqing      

楼上的妙呀:这的是鸡肋－－－－要么很简单，要么很困难
happy programming!   回复  引用  查看    

#20楼 2008-10-29 16:57 牛腩      

目前做着的项目中就用到了,不过感觉不太好用....过段时间了我查数据库的时候发现aspnet_user表里有好多用户名重复的记录哦..郁闷...不知道怎么回事..   回复  引用  查看