从ASP.NET 2.0开始，已经尝试最大限度地将一些公共基础设施统一起来，并引入了Provider模式！其中比较典型有Membership、Profile、Personalization等等，通过这些统一化的基础设施，我们可以编写少量代码甚至不需要编写任何代码就可以达到以前费了九牛二虎之力才能实现的效果，而且这些代码都是经过精密测试的，可以很大程度减少由于这方面代码而引入的问题，所以对于部分网站而言，采用它们是比较经济实惠的！
这里要提及的是的Membership中的UserID问题，不知道出于什么原因，Membership的相关数据表"aspnet_Users"等UserID的类型是uniqeidentifier，也就是说是128位的GUID，也许是为了简单地保证唯一性吧！？但是在公司的既有项目和理想情况下，我希望使用的数据类型是int，特别是在电子商务类型的网站中，UserID和大量数据表比如订单表等关联，而且在统计查询中大量使用到这个字段，如果UserID是uniqueindentifier类型的话，相对int类型而言，查询的速度将受到一定程序的影响（注：未测试），而且在某些时候UserID的作用类似于编号，可读性比较好，在后台维护的时候有一定的便利。
反正不管是历史原因还是什么别的，我们现在需要的UserID必须是int类型！怎么办？ASP.NET提供的Membership中的UserID是uniqueidentifier已经是既成事实，我们无法改变！如果因为它的原因我们便完全抛弃这一套东西似乎又有一点可惜，经过考虑和参考DNN的实现，总结出如下两种解决方案：
在aspnet_Users表中添加一个类型为int的字段BizUserID：具体的业务表都和BizUserID而不是UserID关联，如果没有重新实现MembershipProvider，那么简单起见，我们可以将BizUserID设置为自增长字段！
给aspnet_Users表建立一对一的关联表Users，它们通过原来的UserID关联，Users表另外提供一个类型为int的BizUserID字段，业务表和该字段关联：DNN使用的就是这个方法，为了保持两个表的同步，必须重写MembershipProvider，有一定的工作量，但是由于引入了Users表，我们可以在其中存储一些额外的信息，特别是当你迁移遗留系统，这个方法还是比较简单实用的。
在最后，我有个小小的疑问，不知道大家在实际项目中会直接使用Membership这一套东西呢，还是会自己实现一套新的？我没有什么项目经验，比较好奇，想知道大家是怎么选择的，希望高人赐教！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。