membership,想说爱你不容易

   在asp.net2.0下我们迎来了membership这个似乎和某个框架里很象的东西。可以承认的是在这种模式下我们的代码量确实减少了不少，效率也提高了很多，而且如果你要是对其下的控件了解的很详细的话，基本上任何样式都是可以设定的。然而，我觉得这里面还是有局限性的，我不是说membership不好，象在一个从0开始做的项目的话，选择membership确实是个明智的选择，但是，再好的东西它也不是万能的对吧，并且，接过来的项目不一定都是从0开始的，很多情况可能都迫使你抛弃membership。

   我以前做过的很多项目都是和CS结合到一块的，并且象这样的项目需要把cs的用户登陆信息共享到bs,存储用户信息的是项目组里定义好的一张表，这样一来，membership似乎就失去作用了。因为我们知道，目前来说，membership只能在.net下自动生成的数据库表结构中（sql2005express里或通过aspnet_regsql）才能正常工作，无论你是用什么样的provider,sql200x或者oracle还是access,都要用aspnet_regsql这样的工具来生成这样的结构，当然里面还包括其它的比如webpart信息或则角色信息，这样一来，在类似的项目中，membership似乎就失去了作用，所以用户登陆的逻辑还是要靠自己来定义的。说到这里也许有的老板说“东西是死的，人是活的，你把它生成的表改一下不就可以了么”，是的，我以前也这么想过，但是你知道这个库里面又有多少的逻辑比如存储过程，加一个或减一个字段都可能造成系统的异常，如果某位老板还在较真的话，说“那你就把存储过程什么的都改了，你在大学都学什么了？”没错，这样一来还要重写membership，确实说的有道理，不过我觉得，研究它，经过两到三个项目周期也能略有小成吧。

   而更不爽的，就是webpart存储信息，如果不是windows验证的话，它就根据你membership里的不同用户来存储信息，这样一来webpart似乎也失去了作用，当然你可能问在一个和cs需要结合的项目里要webpart干什么，别忘了我们讨论的是mebership如果失效会怎么样，这个问题不一定是要在和cs结合的项目里才存在的。也许能把membership继承下来根据自己项目的情况来改写里面的逻辑，这样membership似乎也可用了，但是，不晓得开发的难度能有多大，没敢想过。（受此影响的，可能还有profile）
   不过，总的来说，asp.net2.0和vs2005还是有很大的改进的，并且也很跟的上商业和技术的发展，新的数据控件确实可以节省很多的时间和代码量并且思路也清晰多了(关于sqldatasource这类控件，使用过dreamweaver的用户可能觉得和里面的创建数据集很象)，只不过由于很多原因，在东北，这个技术被应用的还是很少的，另外一方面asp.net1.1升级到asp.net2.0给开发人员带来的打击，今年vista发布，好象是.net3也要出来吧，时间似乎很短，而在这样的情况下，是否使用2.0可能也是很多老板考虑的因素之一，当然如果未来10年内世界还和平的话，3.0会是一个很大的革命，伴随着vista的发布。

   以上都是我个人的观点和分析的结论，技术上可能理解的还不到位所以才产生此谬论，欢迎大家批评指正。