Composite Web Application Block是Web Client Software Factory中一个用来开发Web应用的框架，它能帮助程序员更方便的使用MVP模式。关于CWAB的更多信息，请参考这里。
当我们开发SharePoint界面的时候，比如，创建一个Web Part，如果你希望使用MVP模式，是可以引入CWAB的。在这个文档中解释了如何在SharePoint中使用CWAB，但文档里面的一些步骤，其实不一定是最好的。比如，文档中告诉你，将各个程序集放到Web Application的/bin目录中，但我的建议是仍然将它们部署到GAC里面，这样，你就不需要更改Web Application的web.config中的<trust>节点，将代码的默认信任等级提高了。
嗯，总之，我们可以使用CWAB来方便的基于MVP模式来开发Web Part，比如下图所示的项目结构：
上图中的“KBSample.SiteUser.Module”是CWAB中的一个Module项目，包含了与界面UI分离的业务模块。在“Views”目录中包含了定义View的接口和Presenter类：
在“Services”目录中包含了与业务操作相关的Service类：
而“KBSample.SiteUser”项目则是专门的SharePoint项目(你可以选择使用VSeWSS，或是其它你习惯的工具)，其中包含了用来定义Web Part界面的View的实现。
在下面所示的Service接口中，定义了用来真正和SharePoint Object Model交互以获取数据的Service：
在Module被初始化时，将上面的Service注册到Container中：
对View接口的定义：
在Presenter里面，通过[ServiceDependency]来注入所依赖的Service对象(CWAB通过ObjectBuilder来干这件事)，同时定义了当View被载入时的操作：
View是通过一个用户控件来实现的，它实现了View接口，通过[CreateNew]来将一个新的Presenter对象注入进来：
别忘记在View被载入时，也要执行一下Presenter中的载入方法：
如果你熟悉Web Client Software Factory的话，那么在SharePoint开发中引入CWAB应该不是一件困难的事情。不过，由WCSF提供的那些Template和Recipe都不能使用了，项目的结构，需要我们来手工维护(这样反而给了我们很大的自由度:)。
在Wikipedia上，对“Web Application Framework”的定义是：
一个Web Application Framework是一个设计为支持动态Web网站、Web应用程序和Web Services开发的软件框架。Web Application Framework的目标是减少在Web开发中，与常见的开发工作有关的问题。例如，许多框架都提供了诸如数据库访问类库、模板框架和会话管理，同时，框架通常都能促进代码复用。（注：http://en.wikipedia.org/wiki/Web_application_framework）
Wikipedia的定义虽然清晰明了，但未免过于宽泛。根据这个定义，实际上，我们可以再将Web Application Framework分成两种：
■ Web Application Infrastructure Framework
■ Web Application Building Framework
Infrastrcture Framework提供了用来构建Web应用最底层的各种基础框架，诸如HTTP请求的截取和分配、网站与页面处理框架、会话管理、缓存等等。ASP.NET、PHP、JSP就属于Infrastrcture Framework。
Building Framework则是基于Infrastrcture Framework而构建起来的层次更高的Web应用框架，它的目的包括：
■ 将Web应用开发人员的视角从最底层的网站与页面框架，拉到更上面的基于具体应用的业务功能上
■ 用来支撑大型复杂的Web应用，例如超过上千个网站、上万个页面的Web系统，而且提供对服务器场、负载平衡的支持
在.NET领域，DotNetNuke就是一个典型的Building Framework。有了Building Framework，Web开发人员就可以不用从最底层开始构建Web应用系统，而是可以基于Building Framework，开始构建所需要的应用功能组件。一个Building Framework通常会包含下列内容：
■ 成熟的网站与页面结构框架，使得开发人员不用再基于页面、目录来管理整个Web应用
■ 完善且可扩展的用户、角色与权限管理
■ 灵活的UI模型
■ 内置的数据和文件存储能力
■ 具备完善的功能模块封装型
■ 对必要的功能接口提供API
■ 其他…
对于Web应用的开发来说，从静态网站到动态网站，从Infrastructure Framework到Building Framework，几乎是必然的。随着Web应用越来越复杂，开发人员面临的挑战也越来越大：如何维护和管理上千个网站、上万个页面？如何使Web应用能部署到网络负载平衡的环境中？如何使后台的Services与前台Web请求分离？如何提供完善的系统备份与迁移方案？如果我们必须基于Infrastructure Framework来解决这些问题，那么我们可能得将大部分的项目开发周期，花费在解决这些“底层架构”框架之上（虽然有些开发人员确实更喜欢开发“框架”，而不是一个可用的业务系统）。
当基于Building Framework之上进行开发时，开发人员可以更关注业务需求和业务功能的实现。通常，每一种Building Framework都会有一套专门的对功能模块进行封装和打包的模型，开发人员可以基于这一套模型，将自己开发的功能模块以标准化的方式进行封包。一方面，这样可以使得功能模块的部署变得更简单（避免了基于文件的手工拷贝方式），另一方面，开发人员也更容易的将自己开发的功能模块共享给社区（社区中使用同一套Building Framework的开发人员，可以方便的将拿到的功能模块以标准化的方式部署到自己的环境中）。
待续…
这个操作手册是之前帮一个客户写的，使用了SQL Server 2005 Mirroring来实现SPS 2003的门户的快速恢复，主要目的是在SPS 2003门户的突然不可访问（如数据服务器损坏、服务器群集所在网络不可用等）时，能够用最短时间在另外的地点恢复出门户网站。基本上MOSS 2007的原理类似，参考手册中的方法进行即可。
不过需要注意的是，在决定用SQL Server 2005 Mirroring来实现快速备份和恢复之前，你需要根据你的服务器场环境的具体情况，确定是否SQL Server 2005 Mirroring这种方式确实适用于你的服务器场环境。考虑的因素包括：
■ 对快速恢复所花费时间的要求
■ 网络情况
■ 评估Mirroring可能造成的性能上的损失
点击此处下载。
