更改方法:

打开 C:\Documents and Settings\Administrator\Local Settings\Application Data\Microsoft\VisualStudio\8.0\browsers.xml

一、异步IO
        对于应用程序而言，有两种类型的IO调用：即同步IO 与异步IO。其本质的区别是：同步IO会block当前的调用线程，而异步IO则允许发起IO请求的调用线程继续执行，等到IO请求被处理后，会通知调用 线程。在windows平台上，应用程序可以调用CreateFile API, 并通过设置FILE_FLAG_OVERLAPPED标志来决定是否发起异步IO请求。
        对于异步的IO请求，其最大的好处是：慢速的IO请求相对于应用程序而言是异步执行，这样可以极大提高应用程序的处理吞吐量。发起IO请求的应用程序需要关心的是IO执行完成的结果，而不必忙等IO请求执行的过程。
       事实上，无论对于同步IO，还是异步IO,当IO请求发送到device driver后，device driver的执行总是异步的,当它接到IO请求之后，总会马上返回给IO System。而IO System是否立即返回给调用线程，则取决于FILE_FLAG_OVERLAPPED标志的设置,如下图：

二、异步IO的同步问题。
        我们使用异步IO，是为了提高应用程序的处理吞吐量。但是，当异步IO不再异步时（无论你是否设置FILE_FLAG_OVERLAPPED标志），应用 程序的性能会受到极大的影响。根据Microsoft Knowledge Base 156932, 在下列几种情况下，异步IO会失去它的异步性，而表现出同步的性质：
1）如果文件使用了NTFS compression压缩，则system driver不会异步地存取这样的文件。
2）扩展文件长度的IO操作不会是异步操作。
3）Cache机制。如果IO操作使用了file system cache，则这样的IO操作会被当成同步IO,而非异步IO。
即使你使用了FILE_FLAG_OVERLAPPED标志。在这种情况下，
a.如果需要读取的数据已经在Cache里，那么I/O drivers会认为这样的IO请求可以被立即处理，其结果是ReadFile 或者WriteFile调用返回TRUE，表示是：同步处理完成。
b. 如果需要读取的数据不在Cache里，windows NT的file system是使用page-faulting机制来实现cache管理，而page-faulting总是被同步处理， Windows NT没有提供异步的page-faulting机制。的确， file system driver使用了线程池来缓解这一问题，但是，当应用程序发起的IO请求足够多时，线程池还是不能应付的。
        在我们开发基于异步IO应用程序时，应该避免上述问题的出现，因为它们会使程序的性能大打折扣。
那么，对于Cache,我们如何避免呢？答案是：请使用FILE_FLAG_NO_BUFFERING标志。这个标志会使异步IO真实地异步执行。
三、性能的测试数据（仅供参考）。
      我在我的机器上，简单地对使用FILE_FLAG_NO_BUFFERING标志的异步IO,与不使用FILE_FLAG_NO_BUFFERING标志的异步IO进行了对比。
操作：顺序读取1G的文件。
x轴表示：每次读取的字节数（单位：K/每次）
Y轴表示：读取完成所需要的时间。（单位：millisecond)
注意：每次测试读取的内容总数是相等的（1000M）。
例如：如果每次读取128k,则需要读取8000次(128k*8000 = 1000M)。
如果每次读取256k,则需要读取4000次(256k*4000 = 1000M)。
粉红色的线没有使用FILE_FLAG_NO_BUFFERING标志,而黄色的线使用了FILE_FLAG_NO_BUFFERING标志。

从以上的数据,我们可以得出以下结论:
1) 当使用FILE_FLAG_NO_BUFFERING标志，应用程序的性能会极大提高，大概有50%的提高。
2） 在使用异步IO的时候，还有一个注意的问题是：当你每次读取的字节数增大的时候，性能也会提高。尤其在小于1024k时，当增大次读取的字节数，性能都有 明显的提高。在混合了网络传输等复杂因素的应用程序开发过程中，建议将该值设置为可配置的参数，通过调整该参数，使你的应用达到最好的性能。

参考资料：

1） Microsoft Knowledge Base 156932

2)  Microsoft Windows Internals, Fourth Edition.

1.2 MVC架构
MVC最初是在Smalltalk-80中被用来构建用户界面的。M代表模型Model, V代表视图 View， C代表 控制器Controller。
MVC的目的是增加代码的重用率，减少数据表达，数据描述和应用操作的耦合度。 同时也使得软件可维护性，可修复性，可扩展性，灵活性以及封装性大大提高。
单用户的应用通常是以事件驱动的用户界面为组织结构的。开发人员用一个界面工具画了一个用户接口界面，然后编写代码根据用户输入去执行相应的动作，许多交互式的开发环境鼓励这么做，因为它强调先有界面然后再有功能。一些软件设计模式策略是这样的，然后经常将固定后的代码融入最后的系统当中。导致的结果就是，程序组织围绕用户界面元素和用户在那些界面元素上的动作，数据的存储，应用的功能以及用来显示的代码都杂乱无章的缠绕在一起。在单用户的系统里代码结构是可以这样的，因为系统需求不会频繁变化。但是对一个大的系统如大型Web系统，或电子商务系统来说就不太适用了。
通过把数据模式从各种可以被存取和控制的数据中分离出来可以改善分布式系统的设计。MVC设计模式由三部分组成。模型是应用对象，没有用户界面。视图表示它在屏幕上的显示，代表流向用户的数据。控制器定义用户界面对用户输入的响应方式，负责把用户的动作转成针对Model的操作。Model 通过更新View的数据来反映数据的变化。
三者关系如图：

2.2 Composite模式
MVC的一个重要特征就是View可以嵌套。嵌套的组合视图可用于任何视图可用的地方，而且可以管理嵌套视图。这种思想反映出将组合的视图与其组件平等对待的设计。这种设计思想在面向对象领域内被描述成为Composite的设计模式。
模式类型：Composite模式是对象型模式，同时它也是结构型模式。
模式目的：将对象组合成树形结构以表示"部分-整体"层次结构。Composite使组合对象的使用和单个对象的使用具有一致性。
模式结构：

图4. Composite模式的结构图
效果：
1. 定义了包含简单对象和组合对象的类层次结构。简单对象可以被组合到复杂对象中，而组合的对象可以再被组合。这样客户端代码中用到简单对象的地方都可以使用组合对象。
2. 简化客户端代码。客户端不用知道某对象是简单对象还是组合对象，可以以一致的方式使用这些对象。
3. 更容易增加新类型的组件。新的组件可以方便地加入已有组合对象中不用改变客户端代码。

2.3 Strategy模式
MVC的另一重要特征是可以在不改变View的情况下改变View对用户输入的响应方式。这对一个经常需要变更响应逻辑的系统来说是非常重要的。MVC把响应逻辑封装在Controller中。有一个Controller的类层次结构，可以方便地对原有Controller做适当改变，创建新的Controller。View使用Controller子类的实例来实现一个特定的响应策略。要实现不同的响应策略，只要用不同种类的Controller实例替换即可。还可以在运行时刻通过改变View的Controller来改变View对用户输入的响应策略。这种View-Controller的关系是被描述为Strategy的设计模式的一个例子。
模式类型：Strategy模式是对象型模式，同时它也是行为型模式。
模式目的：定义一系列的算法，并且把它们封装起来，使它们可以互相替换，使得算法可以独立于使用它的客户端而变化。
模式结构：

图5. Strategy模式的结构图

效果：
1. Strategy类层次为Context定义了可重用的相关算法或行为。
2. 替代继承的方法。如果直接继承Context，给以不同的行为，会将行为加到Context中，从而将算法的实现与Context混合起来，使Context难以理解，维护和扩展，而且不能动态地改变算法。将算法封装在独立的Strategy类，可以使得算法独立于Context改变，容易切换扩展。
3. 可以提供相同行为的不同实现。
4. 客户端必须了解Strategy之间有何不同。
5. Context和Strategy之间的通信开销。
6. 增加了对象的数目。

3. MVC在 Web系统中的应用
现在的一些基于Web的分布式系统如B2B电子商务系统，就适合采用MVC架构。
通过分析，从高层次的角度可以将一个应用的对象分为三类。一类就是负责显示的对象，一类对象包含商业规则和数据，还有一类就是接收请求，控制商业对象去完成请求。这些应用的显示是经常需要变换的，如网页的风格，色调，还有需要显示的内容，内容的显示方式等。而商业规则和数据是相对要稳定的。因此，表示显示的对象View经常需要变化的，表示商业规则和数据的对象Model要相对稳定，而表示控制的Controller则最稳定。
通常当系统发布后，View对象是由美工，HTML/JSP设计人员或者系统管理员来负责管理的。Controller对象由应用开发人员开发实施，商业规则对象和商业数据对象则由开发人员，领域专家和数据库管理员共同完成的。显示逻辑在Web层或客户端控制，可以是Servlet 或JSP，动态地生成Html。一般来说采用JSP要比采用Servlet要好。JSP更好地将代码与Html部分分开，有利于页面设计人员和代码开发人员的分离，提高效率。同时JSP可以完成所有Servlet完成的功能，实际上JSP最终也转换成一个Servlet。与控制有关的对象存在于系统的每一个层次，协调跨层动作。包含商业规则和数据的对象存在于EJB层（以EJB为中心的模式）或Web层（以Web为中心的模式）。

3.1 View在Web系统中的应用
View代表系统的显示，它完全存在于Web层。一般由JSP, Java Bean和Custom Tag组成。JSP可以动态生成网页内容，Custom Tag 更方便了使用Java Bean，而且它可以封装显示逻辑，更有利于于模块化和重用。一些设计良好的Custom Tag可以在多个JSP甚至可以在不同的系统里重复使用。Java Bean用来控制JSP和Model对象。JSP通过Java Bean 来读取Model对象中的数据，Model和Controller对象则负责对Java Bean的数据更新。一般来说，可以先要设计出所有可能出现的屏幕，即用户使用系统时可以看到的所有内容。然后根据这些内容，找出公共部分，静态部分和动态变化部分。可以考虑使用模板方法，把公用的内容单独生成JSP，需要变化的也各自生成Html或JSP, 由一个模板JSP, 把这些不同部分动态地引入（include方法）。还有一个要考虑的问题就是屏幕的选择问题，当处理完用户请求，模板被自动调用来显示，这个显示一定要知道用户关心的屏幕是有哪些部分组成。所以可以考虑把所有屏幕的定义放在一个集中的文件里，如一个java文件或文本文件。由于考虑到屏幕定义文件将来的变更可能性，最好使用文本文件如一个XML文件，这样将来更改不用重新编译。可以根据用户输入的URL和参数可以映射到某一个结果屏幕，当然有可能还要根据动作的执行结果选择不同的结果屏幕内容。所以需要一个请求与资源的匹配文件（XML），如果一个URL请求有几种不同结果，则要在该文件中指明是否需要流控制（一种controller对象）以及不同流向的对应屏幕。

3.2 Model在Web系统中的应用
Model对象代表了商业规则和商业数据，存在于EJB层和Web层。在J2EE的规范中，系统有些数据需要存储于数据库中，如用户的账号信息（account model），公司的数据(company model)等，也有一些不需要记录在数据库里的，如某用户浏览的当前产品目录(catalog model)，他的购物内容(shopping cart model)等。这些model数据存在于哪一层要根据它们的生命周期和范围来决定。在Web层有HttpSession和ServletContext及Java Bean对象来存储数据，在EJB层则有EJB来存储数据和逻辑。Web层的Java Bean的model对象存储了EJB层model对象的数据的拷贝。因为EJB层有很多不同的model对象，所以Web层可以通过一个ModelManager来控制EJB层的各model对象，在ModelManger中可以封装使用后台model对象的方法。
在EJB层把所有的数据和规则都模式化为EJB也是不恰当的。如可以把存取数据库的对象模式化为DAO对象。DAO中可以封装与具体数据库的交互细节，如可以读写不同的表，多个数据库，甚至多种数据库。如定单的model对象可以是一个OrderDAO, 它可能要同时处理Order表，OrderStatus表和OrderItemLines表。
还有可以考虑使用Value对象。一个Value 对象可以封装远程对象，因为每一个读远程对象的属性都可能是一个远程过程调用，都会耗费网络资源。可以在EJB的远程对象中使用Value对象. 在远程对象中一次性得到Value对象来得到所有属性的值。

3.3 Controller在Web系统中的应用
Controller对象协调Model与View，把用户请求翻译成系统识别的事件。在Web层，一般有一个MainServlet(或Main.jsp)，接收所有请求，它可以调用屏幕流管理器（ScreenFlowManger）决定下一个屏幕。一般还有一个请求处理器RequestProcessor，包含所有请求都需要做的处理逻辑，如把请求翻译成系统事件（RequestToEvent）。请求处理器通常还包含一个代理对象ClientControlWebImpl，它是EJB层的逻辑处理的在Web层的代理。在EJB层，有一个ClientController提供Web 层对EJB层的只读访问。还有一个StateMachine用来建立和删除ejb，处理Web层送来的事件。
Controller还有一个重要的功能就是同步View和Model的数据。在ModelManger中包含一个ModelUpdateManger，它把系统事件转换为一个Model的集合，即所有需要同步的Model，然后通知Listeners去做同步操作。

4. 结束语
近年来随着互联网技术的发展和新的商业模式的出现，必然会出现大量基于Web的应用系统。对于如何设计这些系统的体系结构，也逐渐有了一些统一的认识，最主要的是的就是其体系结构要合理，开放。需求永远会比技术和设计思想发展快，要使将来系统的升级所付出的代价最小，研究软件系统的体系结构还是非常很用和有必要的。

参考文献
[1] 设计模式，作者Erich Gamma 等，ISBN 7-111-07575-7, 机械工业出版社 2000.9
[2] Core J2EE Patterns, 作者Deepak Alurm 等, ISBN 0-13-064884-1, Sun Microsystems Inc, 2001年
[3] Designing Enterprise Applications with the J2EETM Platform, 作者Nicholas Kassem 等， Sun Microsystems, Inc. 2000年

² 下一个将执行的方法是AddParsedSubObject方法，这个方法将添加所有独立的控件并把页面组成一个控件集合树，这个方 法经常被一些高级的页面模板解决方案(Page Template Solutions)重写以便添加页面内容到页面模板（Page Template）中一些特殊的控件中。这个方法递归应用到所有的页面控件及相应的的每个子控件，所有的控件都是在这个方法中开始最早的初始化。

² 页面类中下一个将执行的方法是DeterminePostBackMode。这个方法允许您修改IsPostBack的值及相关的事件。如果您 需要从数据库中加载ViewState这个方法将特别有用，因为ViewState只有在IsPostBack为真的情况下才会进行恢复。返回空将会导致 强制执行非回传，返回Request.Form则强制执行一个回传。除非在特殊情况下，否则并不建议去操作这个，因为这个还会影响其他的事件。

² 下一个将要执行的方法是OnInit方法，一般这是第一个真正被使用的方法。这个方法触发时，所有页面定义中的控件执行初始化，这意味着所有在 页面中定义的值应用到相应的控件上。不过，ViewState和传回的值还不会应用到控件上，因此，任何被代码或用户改变的值还没有被恢复到控件上。这个 方法通常是最好的创建、重创建动态控件的好地方。
l 恢复及加载
² 下一个方法， LoadPageStateFromPersistenceMedium只会在页面被回传的时候才会被执行。如果因为使用Session或自定义存储方 式，您修改了后面将要提到的影响ViewState保存方式的方法SavePageStateToPersistenceMedium，则这个方法需要被 重写。默认的实现中ViewState是一种Base64格式编码，并且被保存在页面的隐藏域中，您可以使用这篇文章中提及的方法修改ViewState 按以上两种方式保存。注意：这个方法并没有真正加载ViewState到页面或页面控件中。

² 当得到ViewState后，下一个方法LoadViewSate，将以递归的方式恢复ViewState到页面及各个页面控件或子控件中。这 个方法执行后，每个控件都将恢复到上一次的状态，但是用户提交的数据还没有应用到控件上，因为他们不是ViewState的一部分。这个方法主要用于恢复 您在其他事件中动态生成的控件的值，他们的值是您手动保存在ViewSate中，并且现在已经失效。

² 下一个方法是ProcessPostData，这个方法也同样是回传的时候才会被执行，并且不允许被重写，这个是页面基类的私有方法。这个方法 通过匹配控件的名称恢复相应的用户提交的控件的值，到这一步意味着整个页面都已经被完全恢复了。唯一要记住的是所有动态控件的创建必须在这个方法之前。这 个方法也是记录后面的改变事件的方法。

² 下一个方法是OnLoad方法，通常这是用得最多的方法，因为这个方法是页面生存期第一个恢复了所有值的地方。大多数代码根据判断 IsPostBack来决定是否重新设置控件状态。您也可以在这个方法中调用Validate并且检查IsValid的值。也可以在这个方法中创建动态控 件，并且该控件的所有的方法都会被执行以追上当前页面的状态包括ViewSate，不过不包括回传的值。
l 事件处理
² 下一个方法还是 ProcessPostData，实际上就是前一个方法的另一次调用，它仍然是只在回传的时候执行并且由于是私有方法不可以被重写。如果您是第一次看页面 的运行轨迹也许会觉得这个方法有些多余。但实际上这个方法是必要的因为在OnLoad中创建的动态控件也需要他们回传的值。任何在这以后创建的控件将可以 得到他们的ViewState，但是不能再得到他们的回传的值，并且不会触发任何值改变事件(Change Event)。

² 下一个方法，RaiseChangedEvents，也是只在回传页面中执行，并且也因为是基类的私有方法所有不能被继承。在整个页面生存期 中，是在这儿根据之前的ProcessPostData记录的控件的值和提交的值是否不同来触发值改变事件。您也许需要调用Validate或者检查 IsValid的值。这里并没有特别的说明多个值改变事件的执行先后顺序。

² 下一个方法，RaisePostBackEvent，同样是因为是基类的私有方法不能被继承，同样也是只在回传页面中执行。除非使用了 AutoPostBack，不然这是实际提交表单事件执行的地方，特别是按钮或者其实使用javascript提交表单等。如果还没有被手动调用过并且使 用了验证控件，那么Validate会被调用。注意IE中有个BUG有时会允许提交但却不触发任何事件。

² 下一个方法是OnPreRender，一般这是在客户端展现页面之前改变页面及其控件的最后一次机会。您也可以在这个方法里面创建动态控件，并 且所有的方法都会被执行以追上当前页面的状态包括ViewSate，但是私有方法将不会被执行，这意味着不会有回传的值并且不会有事件触发。由于IE中的 BUG，这是一个没有事件赶上PostBack的好地方。
l 保存及显示
² 下一个方法是SaveViewState，不论是否是回传页 面，均会递归的执行以保存页面及其所有控件的ViewState。ViewState基本上保存所有与定义在aspx中的原始值不同的值，不管是被代码还 是用户所改变。注意控件值是根据他们在页面的控件树中的位置来保存的，所以如果动态控件后来加到了错误的位置将会导致混乱。

² 下一个方法是SavePageStateToPersistenceMedium真正的保存页面的ViewSate。这个方法随同 LoadPageStateFromPersistenceMediumg 一起被重写以便保存ViewState到Session或其它自定义数据，而不是用隐藏域。这对于低带宽的用户来说是很有帮助的。并且对于移动设备来说， Session是默认设置。下面这篇文章描述了使用以上两种方式保存ViewState的具体细节。注意在Asp.net中有个Bug：Asp.net要 求必须提交__viewstate字段，即使是空的。

² 下一个方法是Render方法，该方法递归的创建并发送相应控件的html给浏览器。这个方法被一些页面模板方案重写以添加一些通用的页面头与 脚而不使用服务器控件，他们总是有一些额外的东西。注意这儿的修改只能使用纯HTML，因为控件在这儿已经被生成了。您可以用 StringBuilder，StringWriter，HtmlTextWriter捕获相应的HTML输出。

² 最后的方法是OnUnload，这个方法会调用相应的Dispose方法。这个方法提供机会以便清空该页面中使用的非托管资源，如关闭打开的文 件句柄，以前打开的数据库连接等。注意这个方法是在页面已经发送到客户端以后执行的，所以它只有影响服务器对象，并且它不会显示在页面的显示轨迹中。这就 是页面的生存期，对于每一次请求都是这么运行的。
l 作者简介(略)

表1：页面事件总结

方法回传控件

ConstructorAlwaysAll
AddParsedSubObjectAlwaysAll
DeterminePostBackModeAlwaysPage
OnInitAlwaysAll

LoadPageStateFromPersistenceMediumPostBackPage
LoadViewStatePostBackAll
ProcessPostData1PostBackPage
OnLoadAlwaysAll

ProcessPostData2PostBackPage
RaiseChangedEventsPostBackPage
RaisePostBackEventPostBackPage
OnPreRenderAlwaysAll

SaveViewStateAlwaysAll
SavePageStateToPersistenceMediumAlwaysPage
RenderAlwaysAll
OnUnloadAlwaysAll