目前工作需要虽然未要接触到ASP.NET，但本着先天下之忧而忧精神，在空余时间还是要进补一下。
从今天开始研究Discuz!NT。
下载好了Discuz!NT 2.0正式版源代码，解压一看，一个解决方案包含了20个项目，心中暗喜，戴志康这次把这么大的一个项目开源了？
国内开源组织有望咯。
因为本人成长是从asp到.net (win form，在做win form项目时学会OO)的，所以看回web项目一种潜意识驱使先看数据访问层(Discunz.Data.*)，
数据访问层分为Discuz.Data; Discuz.Data.SqlServer; Discuz.Data.Access; Discuz.Data.MySql; 单从项目结构组织上看扩展性挺强，
日后我要写一个Oracle或FireBrid的支持，增加一个对应的实现就行了，为了证实我这想法，就打开了Discuz.Data项目看看。
Discuz.Data 有一子文件夹『DbProvider』，顶层有2个类，一个是 数据异常类 例外一个是 辅助类，再展开DbProvider有2个接口和一个DatabaseProvider类，
从命名上看，大概知道IDataProvider是负责读写BBS数据的，那就先分析它吧，不打开由自可，一打开把几火，哪有这样定义接口的，接口方式开发的原则是“向修改
关闭，向扩展开放”，Discuz竟然把所有的数据表操作要在这个IDataProvider接口中实现，4800行代码，扣除注释应该也有1000来个方法定义吧。（具体有多少个
方法要实现，有兴趣的朋友可以用反射技术来统计一下），而且接口定义的方法多数是具体方法，抽象层次太低，
/// <summary>
/// 获取帖子分表信息
/// </summary>
/// <returns></returns>
DataTable GetTableListInfo();
/// <summary>
/// 获取目标板块名
/// </summary>
/// <param name="targets"></param>
/// <returns></returns>
DataRowCollection GetTargetsForumName(string targets);
如果日后增加一个“获取目标模块下某个用户的帖子”的方案，按他现在这种设计思路，要在IDataProvider接口中改，接口一改，几个实现类也同时改了，
还有，设计是基于“表模式”而非“ORM”，对于用户量这么多与使用量这么广的项目来说，无疑埋下了极大的安全隐患。
总结吧。。。。
今天只看了数据层，是基于接口编程来避免需求改变带来的代码修改，但它只能避免数据库替换时的需求，不能避免到业务逻辑上的需求变化。
至于数据访问方式哪里，有朋友可能会说 表模式 比 ORM 性能要好，这个在.net 3.5之前是事实，但是MS现在推LinqToSql，这个ORM的
性能已经不低于 表模式的性能了，例外还有些组织在做LinqToMySql了。。。。。。
站在我的角度去看，Discuz!NT可以是之前那批PHP程序员写的，对于OO，接口编程这些理解应该也不很深入，一个这么庞大的接口，到实际
应用环境冗余量多大啊。明天星期一了，又要上班啦。。。至于Discuz!NT我还是会研究下去的，毕竟我这次研究目的是学习asp.net而不是系统架构，
希望在未来我能找到非名气的其他理由去为Discuz说好话吧。
我的blog：
http://chenjiabin.spaces.live.com
