迟来的2009 .Net大会总结

序言

参加这次 .Net 大会，对我而言还是收益非浅的。虽然大部分课程，由于时间关系，只能点到即止，但是从中还是学到了不少东西，收到了不少的启发。总体来说，大会课程的主体可以归为技术，设计，过程管理 3 大类，以下就这 3 方面分别说一下我的收获和感想

技术

.Net 性能

应该说， .Net 性能方面的课题，是这次大会的一个亮点，请来来 Jeffrey Richter 对此进行讲演，就很多细节上的问题给出很好的回答，对以后的编码工作有很好的帮助，主要包括以下几点：

l  前提：不要修改工作正常的代码，大部分情况下可读性更重要。

l  StringBuilder 的效率要比直接对 String 操作要高效得多

l  对 Unicode 字符操作比 Ansi 字符要高效。

l  Check 和 UnCheck 的代码效率没有差别

l  MashbyRefObject 的性能要远远低于 Object 。

l  Nullable 的性能要低于 Non-nullable （ 3 倍左右）

l  Static , Interface, Instance, virtual 的函数性能由慢到快依次为 Static ， Virtual ， Instance ， Interface 。后三种效率差别不大， Static 的效率要远远低于其他 3 种。

l  不要在循环中直接通过反射调用方法，因该在循环外获取反射的 MethodInfo 对象，然后重复调用 Invoke 方法。或者可以用 Delegate.CreateDelegate 方法。

l  参数数组比固定个数参数要慢，除非参数数组传递的参数为 null

l  AddRange 方法比 Add 要快的多

l  直接 foreach 集合要比 foreach 集合的 IEnumerable 快的多， For 循环比 foreach 要快的多， List.ForEach （ m ）比 foreach 快（但是做试验的时候失败）

l  线程同步时 lock( 即 Moniter.Enter/Exit) 速度最快，但是适用与线程数较小的情况下， ReadWriteLockSlim 的速度较慢，但是适用于线程数较多的情况下（原因是 lock 一次只能让一个线程进入，而 ReadWriteLockSlim 可以一次让多个线程同时进入）。不用使用 ReadWriteLock ，而由 ReadWriteLockSlim 代替。 Mutex 速度最慢，一般适用于跨边界同步。

l  线程是昂贵的，无论是创建还是销毁（ .Net 下每个线程会占用 1M 多的内存）。线程会加重垃圾回收的负担。

l  在 .Net 下尽使用 .Net 的线程池，即使你只需要一个工作线程（线程池会智能的维持最优线程数量）。

l  不要 Block 线程，这样会使线程池创建新的线程从而造成资源浪费

l  IO 设备基本上都有自己的 CPU ，对 IO 操作并不占用本机 CPU 资源，应该使用异步操作，同步的 IO 操作会造成资源的浪费。

使用 WinDebug+SOS 深入理解托管世界

这堂课由于时间的关系，其实牵涉的内容并不是很多，主要介绍了 WinDebug+SOS(SOS 是 WinDebug 调试 .Net 程序的一个扩展，安装了 .Net FrameWork 会自动安装 ) 的用法。在介绍了用法的过程中也提到了 .Net 程序的加载和垃圾回首机制的原理。总结下来就是这么几条 :

l  .Net 程序和普通 EXE 程序一样，都有一个 PE 头， .NET 程序的 PE 头中只是增加了 CLR Header 描述一些特有信息。

l  _CoreExeMain 是 .Net 应用程序开始执行的起点，该函数与版本无关，在该函数里获得版本信息加载相应版本的 .Net 支持库。

l  系统先创建一个 SystemDomain ，在 SystemDomain 中创建默认的 AppDomain 和 ShareDomain （一个 Domain 就是一个程序运行时的虚拟机），之后创建垃圾收集工作线程（垃圾收集线程工作逻辑就是不停的等待信号，在一定的时间调用所有无引用对象的析构函数）。

l  在以上步骤执行完后， SystemDomain 才开始调用程序 Main 函数，开始加载 Assembly 。

l  .Net 的实时编译是先调用后编译，即第一次调用时系统发现函数未编译，此时加载 JIT 编译并替换函数头中的入口地址和方法表，这样下次调用就可以不用再次编译。

Windows 平台安全框架与设计经验谈

这堂课同样由于时间关系并没有将太多的的内容，只是简单介绍了一下 Windows 的认证机制原理，主要提到以下关键点：

l  计算机和登录会话（ Logon Session ）本身就是一个安全主体，拥有自己的 SID 。

l  Windows 认证保存的是完全主体的凭据而不是用户名和密码，凭据由系统通过验证用户名和密码获得，其中包含了用户的身份。 NTLM 和 AD 验证的本质都是将密码作为密钥使用，密码本身不会在网络上传递，而两者区别在于 NTLM 用户验证传递的是通过用户密码作为密钥加密的内容，而 AD 传递的是一个验证请求，由 AD 返回的内容包含以用户密码为密钥加密何以 AD 自身的密码为密钥加密的 2 部分内同。因此只有 AD 才能实现身份模拟而 NTLM 不能实现的（因为需要模拟的中间计算机拿不到用户密码）。

l  登录时系统需要创建登录会话，一次登录就有一个登录会话。登录会话分为系统登录会话，网络登录会话，服务登录会话，批处理登录会话，交互式登录会话 5 种。当服务已 Local System 权限运行时，登录使用的是系统登录会话，而使用指定的用户身份运行时，登录使用的服务登录会话。

l  创建登录会话后， LSA 会创建访问令牌，并和登录会话管理，一个登录会话可以关联多个访问令牌，而进程关联的是访问令牌，进程下的线程可以使用进程的访问令牌，也可以使用自己的令牌，（通过令牌，在某个登录会话中，进程和线程可以间接的改变安全属性）。

l  我们在设计自己的系统时，使用 Windows 的认证方式就必须做到不能保存和传递用户密码（即使加密的密码也不行），必须使用中间层模拟用户权限的方式（举例就是 A 计算机通过 B 计算机的服务访问 C 计算机的数据库，此时 B 计算机必须模拟 A 计算机的身份访问 C 计算机而不能直接使用自己的身份访问 C 计算机），否则即使使用 Windows 的认证方式，其安全性也不复存在。

l  《 .Net Devloper’s Guid to Windows Security 》和《 Programming Windows Security 》这 2 本书在这方面写的很好。

Azure Service Platform 的 .Net Services 和 Silverlight Networking

这两门课本身并没有什么技术含量，一是介绍了 Azure Service Platform 的 .Net Services 所提供的功能，一是介绍 Silverlight 网络编程的一些用法。 Azure Service Platform 的 .Net Services 说白了就是一套 Web 服务，目前提供了一个总线服务（就是把东西发给指定的人），工作流服务（没说，不知道是什么），认证服务（帮你做认证），你可以运用这些服务简化你的开发工作。而 Silverlight 的网络编程说白了就是微软用来代替 JavaScript 的一个在浏览器下运行的简化的 CLR 运行时（当然，它也是编译执行的），让你可以有更好的体验编写富客户端的网页。但是，他同样不能超出浏览器编程的限制，从这点来说，他能超越 JS 的原因也许仅仅是因为它是面向对象的，而 JS 不是（至于他的编译执行，我想在浏览器环境下，这个反而不是什么大优势）。

设计和项目管理

关于设计和项目管理，我不想就每一个课程分别进行描述， 1 是因为这些课程本身由于时间有限，讲师能给大家介绍的本身就是一些纲领性，思想上的概念和经验，我也很难再做一次提炼（要知道细节的可以看 PPT 和听录音）， 2 是这些内容要在工作起作用，要依靠每个人的理解和领悟，在我看来这些内容本身有着很多相关性，放在一起说也许更合适。下面，就说说我通过这几堂讲座，接合我之前在这方面的经验和工作所得出的一些感想和心得。

首先，软件的起点不应该是需求，而是一个目标，这点和 MSF 提到的 Vision Scope 很一致，这个目标限定了我们的所有工作的范围。

然后为了达成这一目标，我们需要满足一系列的需求。因为需求永远是多变的，甚至在你产品递交的前一分钟，它都会发生改变，所以我们要对需求进行分析，分析的目的不是为了得出需求是什么，而是要以达成目标为前提，从这些需求中分离出不变的秩序和多变的内容，要利用这些不变的秩序创造出一个系统框架，来包容这些已知和未知的变化的内容，最后，再将这些变化的内容填充到这样一个框架中，从而使得整个系统完整，能够满足我们为了达到目标所需要一系列的需求。这就是设计

整个过程归纳成一个词那就是求同存异（发掘事物的共性，并利用这些共性创造出一种通用表现形式来包容这些事物的多样性，这就是我对求同存异这个词的新的理解）。而这个词也是设计的意义的所在。设计一个系统，就是对系统达成目标的求同存异，设计一个模块，就是对模块达成目标的求同存异。

而架构设计的结果，在我看来应该就是对系统求同存异的结果，在通过需求分析和逻辑设计，找出了变和不变的那条界线后，由架构设计来创造出这样一个可以包容变化的不变的框架，我想这也正是架构师被称为总设计师的原因。在温昱的讲座中，他提到了一个好的架构设计光有子系统划分和接口定义是不够的，一个完整的系统架构应该说清楚 5 大方面的内容（他称之为 5 视图法）

1、  运行视图，如进程，线程的模型是什么样的

2、  逻辑视图，如系统分层，职责划分，接口定义，结构化方法和模块

3、  物理视图，如服务器选型，系统部署方案

4、  开发视图，如基础的源程序目录（第一，第二层）

5、  数据视图，如数据分布与 Database Schema ，文件格式

我本身在这方面的经验并不丰富，对于他所说的是对是错，是否完整无法做出评价，但是我发现他提到架构设计所需要包含的这些内容，一旦确定后，的确是很少发生变化。

上面这些，是我对设计的一些理解，而关于对项目管理的理解，就更加抽象了，项目管理的目的就是为了让项目（产品也可以看作是项目的一种）能够成功，在项目过程中最关键的是人，一切都是以人为本的，项目管理中引入流程的目的是为了防止人犯错，引入工具是为了提高人的效率。而当人发生了问题时，项目管理的反应就是在范围，资源（成本），时间，和质量中找出新的平衡点从而确保项目的成功或者及时取消项目已避免更大的损失。

而为了达成以上目标的方法，也不外乎，通过将复杂问题分解来降低对人的要求，减少犯错的几率，通过标准和审核机制来解决人的惰性，通过缩小范围，增加输出来缩短反应时间。

因此在我看来，任何方式的项目管理都不是一成不变的，任何方式的项目管理也都可以是相辅相成的，对于一个团队来说，采用什么样的管理不重要，重要的是能够让团队中的人少犯错，多做事，而一旦犯了错能快速相应，也就够了。

总结

以上这些，就是我在参加完这 2 天的课程中所获得收获和启发，特别是在设计和项目管理这 2 个方面，除了在思想上的认识有所提高外，还学到了一些实用的方法何技巧，但是由于我个人的水平有限，如何在今后用上这次培训所学到的内容，还需要不断的努力。当然也有可能，我目前对设计和项目管理理解和认识是不完善，或者是错误的，这也需要在今后的工作中加以验证。同时，我也希望大家能多多指点，共同进步。