跨站脚本Cross-Site Scripting（XSS）又叫CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意 用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。
跨站脚本Cross-Site Scripting（XSS）是最为流行的Web安全漏洞之一。据统计，2007年，跨站脚本类的安全漏洞的数目已经远远超出传统类型的安全漏洞(http://en.wikipedia.org/wiki/Cross-site_scripting)

虽然在IE8中引入了客户端的XSS过滤器以减少XSS对用户造成的危害，但是XSS本质上是Web应用服务的漏洞，仅仅依赖客户端的保护措施是不够的。解决问题的根本是在Web应用程序的代码中消除XSS安全漏洞。

以下是在Web应用的开发中避免XSS安全漏洞的几个原则：

• 检查所有产生动态网页的代码
• 判定动态网页的内容是否包括不安全的输入信息
• 对输入进行校验
• 对输出进行编码以过滤特殊字符

采用不同的Web开发工具，实施以上原则的具体步骤也不相同。当需要将一个字符串输出到Web网页时，但又不能完全确定这个字符串是否包括HTML 的特殊字符，例如“<,>,&”等等，可以使用编码（HTMLEncode）以过滤这些特殊字符。在ASP.NET中有两种方法：一 种是使用HttpUtility，另一种就是使用微软提供的XSS库，最新版本是3.0 ,采用MS-PL协议发布的开源项目，7月14日发布了，下载地址是：http://www.microsoft.com/downloads/details.aspx?FamilyId=051ee83c-5ccf-48ed-8463-02f56a6bfc09&displaylang=en。

AntiXss的使用方式与HttpUtility类似：

String Name = AntiXss.HtmlEncode(Request.QueryString["Name"]);

它们最大的区别在于HttpUtility.HtmlEncode采用的是黑名单验证（Black list）方式。即HttpUtility.HtmlEncode仅仅过滤它知道的特殊字符，而允许其它的输入。AntiXss.HtmlEncode采 用的白名单验证（White list）方式。它只允许输出它认为合法的字符，而过滤掉其它的所有字符。

两者中，AntiXss.HtmlEncode要更为安全，是推荐的使用手段。

在asp.net 程序中避免 Cross-Site Scripting 攻击的正确方法：

(1) ValidateRequest = true

(2) 对于所有使用者的输入加以 编码 并检查长度 ： Application、Session、Url QueryString、Cookie、HTTP Header、数据库、文件、Form表单(根据输出的区域，使用以下相对应的七种编码方法)

XSS Libray 包含如下的方法：

具体的使用方法及示例，请参考MSDN： Microsoft Anti-Cross Site Scripting Library V1.5: Protecting the Contoso Bookmark Page 

AntiXSS Library v3.0 除了保留了老版本的一些静态的Encode工具方法(重新实现),另外最重要的就是新增了
AntiXSS HttpModule 用于统一 Encode 输出ASP.Net Server Web Control 为encode 输出的相关属性,如:Text属性等
原理大概是《利用 HttpModule,基于输出,统一控制、干预、处理(例如: 过滤关键字、AntiXSS) ASP.Net WebForm Control 展现属性的方案原型》
http://www.cnblogs.com/Microshaoft/archive/2009/01/08/1371475.html

微软反跨站脚本库主页：http://msdn.microsoft.com/en-us/security/aa973814.aspx
XSS（跨站）攻击全解析: http://www4.it168.com/jtzt/shenlan/safe/xss/
CodePlex站点: http://antixss.codeplex.com/

这样每次context.Response.Write出支的数据就压缩了

对效多的文本信息压缩可以压缩到原来三分之一到四分之一的样子

如果发送的信息只有几个字节就没有必要了

让浏览器做缓存需要给浏览器发送指定的Http头，告诉浏览器缓存多长时间，或者坚决不要缓存。作为.net的程序员，其实我们一直都在用这种方法，在OutputCache指令中指定缓存的Location为Client时，其实就是给浏览器发送了一个Http头，告诉浏览器这个Url要缓存多长时间，最后修改的时间。

微软在OutputCacheModule中对这些缓存用到的Http头给我们进行了很好的封装，但是了解这些Http头可以更灵活的使用它们。

和客户端缓存相关的Http头有以下几个，分别是：
1. Expires:+过期时间
表示在指定时间后浏览器缓存失效，需要注意的是这儿的过期时间必须是HTTP格式的日期时间，其他的都会被解析成当前时间“之前”，缓存会马上过期，HTTP的日期时间必须是格林威治时间（GMT），而不是本地时间。举例：
Expires: Fri, 30 Oct 2009 14:19:41

使用Expires过期必须要求服务器的时间是正确的，否则发送的http头就会出问题，在windows服务下可以设置时间服务器来同步时间
2. Cache-control:
Cache-control直译成中文就是缓存控制，它的作用就是缓存控制，这个http头的值有几种。
1) max-age=[秒] — 执行缓存被认为是最新的最长时间。类似于过期时间，这个参数是基于请求时间的相对时间间隔，而不是绝对过期时间，[秒]是一个数字，单位是秒：从请求时间开始到过期时间之间的秒数。
2) s-maxage=[秒] — 类似于max-age属性，除了他应用于共享（如：代理服务器）缓存
3) public — 标记认证内容也可以被缓存，一般来说： 经过HTTP认证才能访问的内容，输出是自动不可以缓存的；
4) no-cache — 强制每次请求直接发送给源服务器，而不经过本地缓存版本的校验。这对于需要确认认证应用很有用（可以和public结合使用），或者严格要求使用最新数据的应用（不惜牺牲使用缓存的所有好处）；
5) no-store — 强制缓存在任何情况下都不要保留任何副本
6) must-revalidate — 告诉缓存必须遵循所有你给予副本的新鲜度的，HTTP允许缓存在某些特定情况下返回过期数据，指定了这个属性，你高速缓存，你希望严格的遵循你的规则。
7) proxy-revalidate — 和 must-revalidate类似，除了他只对缓存代理服务器起作用
举例:
Cache-Control: max-age=3600, must-revalidate

很显然Cache-control可以提供比Expires更灵活的缓存控制，而且它不需要依赖于服务器时间。
在Asp.Net中微软把对Cache-control属性的设置封装到了HttpCachePolicy类中，我们可以通过Response.Cache来调用以下方法来做到对Cache-Control Http头值的控制：
Response.CacheControl;
Response.Cache.SetNoStore
Response.Cache.SetMaxAge
Response.Cache.SetProxyMaxAge
Response.Cache.SetRevalidation
           
3. Last-Modified/If-Modified-Since
这两个Http头是一对，前者表示某个地址的最近更新时间，是服务器端响应给客户端的；而后者是客户端浏览器发送给服务器的，告诉web服务器客户端有一个最后更改时间为什么时间的缓存，服务器端接收到If-Modified-Since头后则判断客户端缓存的这份url地址的缓存是否是最新的，如果是最新的则服务器端直接给客户端返回HttpStatus 304，意思是说这个内容在你上次请求之后没有变化过，你直接用缓存就可以了；如果服务器发现url的最后更新时间比If-Modified-Since 的值要新，则会输出新的内容。

同样微软也为我们做了服务器端设置的封装，我们可以这样调用
Response.Cache.SetLastModified(DateTime)
Response.Cache.SetLastModifiedFromFileDependencies()

如果有更复杂的需求就需要自己处理了。

4. ETag/If-None-Match
ETag和Last-Modified类似，不过他发送的是一个字符串来标示url的版本，如果url变了则此标示也跟着变化，在浏览器发送If-None-Match时告诉浏览器内容已经变了，或者没变可以使用缓存。

Iis会自动给静态文件加上Etag，在文件发生改变时重新生成一个Etag，这样对于一个网站中的n多个静态文件如：样式表，小图片等，客户端只下载一次就够了，可以减轻负载。

在Asp.Net中我们可以用以下两个方法来设置
Response.Cache.SetETag(string)
Response.Cache.SetETagFromFileDependencies()

尽管微软为我们做了很多封装，但是我们还是需要详细的了解之后才可以用好这几个Http头。

问题：当一个正在执行中的ASPX页面执行到一半的时候，浏览器中你关闭了这个页面，服务器端对应的这个页面的代码仍然在执行么？

答案：除非你代码里面做了特殊判断，否则仍然正在执行。

注意点：

1、客户端显示页面的时候，后台已经执行完了的页面对象早已经不存在了。当然这时候谈不上服务器段执行不执行的问题了。

2、页面还没有返回，处于等待状态的时候。关闭ASPX页面，才会涉及到上面提到的服务器端仍然在执行的情况。

3、客户端关闭的时候根本不向服务器发送指令。

4、除非你代码里面做了特殊判断，这里的特殊判断指用 if(!Response.IsClientConnected) 来检测状态而用代码终止运行。

下面的简单代码就是演示关闭页面后，看是否仍然在执行？

你可以在这个页面打开后， 还没有返回任何信息的时候把这个页面关闭，然后看指定目录下是否有对应文件被创建并填写内容。

        protected void Page_Load(object sender, EventArgs e)
{
StringBuilder txt = new StringBuilder();
txt.AppendLine();
txt.AppendLine(DateTime.Now.ToString("u"));
txt.AppendLine("asvd");
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
Thread.Sleep(50000);
txt.AppendLine(DateTime.Now.ToString("u"));
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
// 把一些信息写到另外一个文件,借此察看是否正在运行
string dir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "logs");
if (!Directory.Exists(dir))
Directory.CreateDirectory(dir);
DateTime dt = DateTime.Now;
string shortfileName = string.Format("errors_{0:0000}{1:00}{2:00}.log", dt.Year, dt.Month, dt.Day);
string fileName = Path.Combine(dir, shortfileName);
StreamWriter sw;
if (File.Exists(fileName))
sw = File.AppendText(fileName);
else
sw = File.CreateText(fileName);
sw.Write(txt.ToString());
sw.Close();
sw = null;
}

作了特殊判断的情况简单例子：

注意： IsClientConnected 的判断在 VS.net 开发工具自带的开发站点 ASP.NET Development Server  是不支持的。 ASP.NET Development Server 永远返回 true 。

IIS 才是支持的。

        protected void Page_Load(object sender, EventArgs e)
{
StringBuilder txt = new StringBuilder();
for (int i = 0; i < 100; i++)
{
if (this.Response.IsClientConnected)
{
txt.AppendLine();
txt.AppendLine(DateTime.Now.ToString("u"));
txt.AppendLine(i.ToString());
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
Thread.Sleep(500);
}
else
{
Response.End();
return;
}
}
txt.AppendLine(DateTime.Now.ToString("u"));
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
// 把一些信息写到另外一个文件,借此察看是否正在运行
string dir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "logs");
if (!Directory.Exists(dir))
Directory.CreateDirectory(dir);
DateTime dt = DateTime.Now;
string shortfileName = string.Format("errors_{0:0000}{1:00}{2:00}.log", dt.Year, dt.Month, dt.Day);
string fileName = Path.Combine(dir, shortfileName);
StreamWriter sw;
if (File.Exists(fileName))
sw = File.AppendText(fileName);
else
sw = File.CreateText(fileName);
sw.Write(txt.ToString());
sw.Close();
sw = null;
}

这个例子中是发现中断，就抛弃之前做的任何东西。

当然我们也可以简单的修改上述代码，让把已经处理完成的东西记录下来，类似下面的代码

        protected void Page_Load(object sender, EventArgs e)
{
StringBuilder txt = new StringBuilder();
for (int i = 0; i < 100; i++)
{
if (this.Response.IsClientConnected)
{
txt.AppendLine();
txt.AppendLine(DateTime.Now.ToString("u"));
txt.Append("**********  ");
txt.AppendLine(i.ToString());
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
Thread.Sleep(500);
}
else
{
break;
}
}
txt.AppendLine(DateTime.Now.ToString("u"));
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
// 把一些信息写到另外一个文件,借此察看是否正在运行
string dir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "logs");
if (!Directory.Exists(dir))
Directory.CreateDirectory(dir);
DateTime dt = DateTime.Now;
string shortfileName = string.Format("errors_{0:0000}{1:00}{2:00}.log", dt.Year, dt.Month, dt.Day);
string fileName = Path.Combine(dir, shortfileName);
StreamWriter sw;
if (File.Exists(fileName))
sw = File.AppendText(fileName);
else
sw = File.CreateText(fileName);
sw.Write(txt.ToString());
sw.Close();
sw = null;
}

需要注意的是， 使用 isClientConnected   是要占用一定的系统资源的。

isClientConnected   实际上需要向客户端输出一点东西，然后才知道客户端是否仍然在线。

这样，除非你的应用非常耗时，否则建议你不要用 isClientConnected   。 免得判断 isClientConnected   使用的资源比你实际业务逻辑使用的资源还要多。

在任何情况下， Response.IsClientConnected 都要有些开销，所以，只有在执行至少要用 500 毫秒（如果想维持每秒几十页的吞吐量，这是一个很长的时间了）的操作前才使用它。作为通常的规则，不要在紧密循环的每次迭代中调用它，例如当绘制表中的行，可能每  20 行或每 50 行调用一次。

参考资料：

how to increase timeout on aspx page?
http://p2p.wrox.com/topic.asp?TOPIC_ID=7504

asp.net能不能在客户端关闭后在后台继续将页面执行完毕？
http://topic.csdn.net/u/20070202/14/85ea5576-907a-4960-9c53-b206a05228e4.html

在 ASP.NET 中使用计时器（Timer）
http://blog.joycode.com/percyboy/articles/3595.aspx

ASP.NET 2.0 中的异步页
http://www.microsoft.com/china/msdn/library/webservices/asp.net/issuesWickedCodetoc.mspx?mfr=true

IsClientConnected的问题
http://topic.csdn.net/u/20080712/19/74fa4070-84bd-4fda-a99b-ac361f874738.html

Response.IsClientConnected 原理和用法
http://blog.51ait.cn/article.asp?id=357    第一个地址比较慢，可以看下一个地址
http://blog.joycode.com/ghj/archive/2008/07/23/115198.aspx

ASP.NET是一个非常强大的构建Web应用的平台，它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用。
绝大多数的人只熟悉高层的框架如： WebForms 和 WebServices --这些都在ASP.NET层次结构在最高层。

这篇文章的资料收集整理自各种微软公开的文档，通过比较 IIS5、IIS6、IIS7 这三代 IIS 对请求的处理过程， 让我们熟悉 ASP.NET的底层机制 并对请求(request)是怎么从Web服务器传送到ASP.NET运行时有所了解。通过对底层机制的了解，可以让我们对 ASP.net 有更深的理解。

IIS 5 的 ASP.net 请求处理过程

对图的解释：

IIS 5.x 一个显著的特征就是 Web Server 和真正的 ASP.NET Application 的分离。作为 Web Server 的IIS运行在一个名为 InetInfo.exe 的进程上，InetInfo.exe 是一个Native Executive，并不是一个托管的程序，而我们真正的 ASP.NET Application 则是运行在一个叫做 aspnet_wp 的 Worker Process 上面，在该进程初始化的时候会加载CLR，所以这是一个托管的环境。

ISAPI：  指能够处理各种后缀名的应用程序。 ISAPI 是下面单词的简写 ：Internet Server Application Programe Interface，互联网服务器应用程序接口。

IIS 5 模式的特点：

1、首先，同一台主机上在同一时间只能运行一个 aspnet_wp 进程，每个基于虚拟目录的 ASP.NET Application 对应一个 Application Domain ，也就是说每个 Application 都运行在同一个 Worker Process 中，Application之间的隔离是基于 Application Domain 的，而不是基于Process的。

2、其次，ASP.NET  ISAPI 不但负责创建 aspnet_wp Worker Process，而且负责监控该进程，如果检测到 aspnet_wp 的 Performance 降低到某个设定的下限，ASP.NET  ISAPI 会负责结束掉该进程。当 aspnet_wp 结束掉之后，后续的 Request 会导致ASP.NET ISAPI 重新创建新的 aspnet_wp Worker Process。

3、最后，由于 IIS 和 Application 运行在他们各自的进程中，他们之间的通信必须采用特定的通信机制。本质上 IIS 所在的 InetInfo 进程和 Worker Process 之间的通信是同一台机器不同进程的通信（local interprocess communications），处于Performance的考虑，他们之间采用基于Named pipe的通信机制。ASP.NET ISAPI和Worker Process之间的通信通过他们之间的一组Pipe实现。同样处于Performance的原因，ASP.NET ISAPI 通过异步的方式将Request 传到Worker Process 并获得 Response，但是 Worker Process 则是通过同步的方式向 ASP.NET ISAPI 获得一些基于 Server 的变量。

IIS6 的 ASP.net 请求处理过程

对图的解释：

IIS 5.x 是通过 InetInfo.exe 监听 Request 并把Request分发到Work Process。换句话说，在IIS 5.x中对Request的监听和分发是在User Mode中进行，在IIS 6中，这种工作被移植到kernel Mode中进行，所有的这一切都是通过一个新的组件：http.sys 来负责。

注：为了避免用户应用程序访问或者修改关键的操作系统数据，windows提供了两种处理器访问模式：用户模式（User Mode）和内核模式（Kernel Mode）。一般地，用户程序运行在User mode下，而操作系统代码运行在Kernel Mode下。Kernel Mode的代码允许访问所有系统内存和所有CPU指令。

在User Mode下，http.sys接收到一个基于 aspx 的http request，然后它会根据IIS中的 Metabase 查看该基于该 Request 的 Application 属于哪个Application Pool， 如果该Application Pool不存在，则创建之。否则直接将 request 发到对应Application Pool 的 Queue中。

每个 Application Pool 对应着一个Worker Process：w3wp.exe，毫无疑问他是运行在User Mode下的。在IIS Metabase 中维护着 Application Pool 和worker process的Mapping。WAS（Web Administrative service）根据这样一个mapping，将存在于某个Application Pool Queue的request 传递到对应的worker process(如果没有，就创建这样一个进程)。在 worker process 初始化的时候，加载ASP.NET ISAPI，ASP.NET ISAPI 进而加载CLR。最后的流程就和IIS 5.x一样了：通过AppManagerAppDomainFactory 的 Create方法为 Application 创建一个Application Domain；通过 ISAPIRuntime 的 ProcessRequest处理Request，进而将流程进入到ASP.NET Http Runtime Pipeline。

IIS 7  的 ASP.net 请求处理过程

IIS7 站点启动并处理请求的步骤如下图：

步骤 1 到 6 ，是处理应用启动，启动好后，以后就不需要再走这个步骤了。

上图的8个步骤分别如下：

1、当客户端浏览器开始HTTP 请求一个WEB 服务器的资源时，HTTP.sys 拦截到这个请求。
2、HTTP.sys contacts WAS to obtain information from the configuration store.

3、WAS 向配置存储中心请求配置信息。applicationHost.config。
4、WWW 服务接受到配置信息，配置信息指类似应用程序池配置信息，站点配置信息等等。
5、WWW 服务使用配置信息去配置 HTTP.sys 处理策略。
6、WAS starts a worker process for the application pool to which the request was made.

7、The worker process processes the request and returns a response to HTTP.sys.

8、客户端接受到处理结果信息。

W3WP.exe 进程中又是如果处理得呢？？ IIS 7 的应用程序池的托管管道模式分两种： 经典和集成。 这两种模式下处理策略各不相通。

本文作者：郭红俊 http://blog.joycode.com/ghj

IIS 6 以及 IIS7 经典模式的托管管道的架构

       在IIS7之前，ASP.NET 是以 IIS ISAPI extension 的方式外加到 IIS，其实包括 ASP 以及 PHP，也都以相同的方式配置（PHP 在 IIS 采用了两种配置方式，除了 IIS ISAPI extension 的方式，也包括了 CGI 的方式，系统管理者能选择 PHP 程序的执行方式），因此客户端对 IIS 的 HTTP 请求会先经由 IIS 处理，然后 IIS 根据要求的内容类型，如果是 HTML 静态网页就由 IIS 自行处理，如果不是，就根据要求的内容类型，分派给各自的 IIS ISAPI extension；如果要求的内容类型是 ASP.NET，就分派给负责处理 ASP.NET 的 IIS ISAPI extension，也就是 aspnet_isapi.dll。下图是这个架构的示意图。

IIS  7 应用程序池的 托管管道模式  经典  模式也是这样的工作原理。 这种模式是兼容IIS 6 的方式， 以减少升级的成本。

IIS6 的执行架构图，以及 IIS7  应用程序池配置成经典模式的执行架构图

IIS  7 应用程序池的 托管管道模式  集成模式

       而 IIS 7 完全整合 .NET 之后，架构的处理顺序有了很大的不同（如下图），最主要的原因就是 ASP.NET 从 IIS 插件（ISAPI extension）的角色，进入了 IIS 核心，而且也能以 ASP.NET 模块负责处理 IIS 7 的诸多类型要求。这些 ASP.NET 模块不只能处理 ASP.NET 网页程序，也能处理其他如 ASP 程序、PHP 程序或静态 HTML 网页，也因为 ASP.NET 的诸多功能已经成为 IIS 7 的一部份，因此 ASP 程序、PHP 程序或静态 HTML 网页等类型的要求，也能使用像是Forms认证（Forms Authentication）或输出缓存（Output Cache）等 ASP.NET 2.0 的功能（但须修改 IIS 7 的设定值）。也因为 IIS 7 允许自行以 ASP.NET API 开发并加入模块，因此 ASP.NET 网页开发人员将更容易扩充 IIS 7 和网站应用程序的功能，甚至能自行以 .NET 编写管理 IIS 7 的程序（例如以程控 IIS 7 以建置网站或虚拟目录）。

IIS 7 的执行架构图（集成托管信道模式下的架构）

小结

IIS5 到 IIS6 的改进，主要是 HTTP.sys 的改进。

IIS6 到 IIS7 的改进，主要是 ISAPI 的改进。

参考资料：

ASP.NET Process Model之一：IIS 和 ASP.NET ISAPI
http://www.cnblogs.com/artech/archive/2007/09/09/887528.html

ASP.NET Internals – IIS and the Process Model
http://dotnetslackers.com/articles/iis/ASPNETInternalsIISAndTheProcessModel.aspx

模组化的IIS 7 与.NET 能力整合
http://www.microsoft.com/taiwan/technet/columns/profwin/33-iis7-componentization-integration.mspx

Introduction to IIS 7.0 Architecture
http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/

我将使用本页链接到有关Silverlight 2的文章和贴子（包括我写的和别人写的），请经常回来查看新的内容，因为我才开始。

入门教程

• Silverlight 2 初览: 我建议先读这个贴子，如果你正考虑开始Silverlight 2开发的话。该文不仅对Silverlight 2提供的功能做了高层次的描述，还链接到了一个八个贴子的系列教程，该教程对如何建造一个Digg客户端例程做了示范。这些教程贴子对Silverlight 2和WPF开发的概念提供了很好的介绍。

• 使用Expression Blend开发Silverlight 2应用 -- 初览: 我建议下载Expression Blend 2.5 三月份预览版，按本教程贴子的步骤进行。我认为它很好地展示了Expression Blend的一些常见功能，用它建造了一个IM聊天客户端例程。

• Unit Testing with Silverlight 2: Silverlight开发团队的Jeff Wilcox有一篇精彩贴子，讨论如何使用Silverlight SDK中的单元测试框架单元测试Silverlight 2应用。

入门讲座

• Building Rich Internet Applications with Silverlight (Part 1 and 2): Joe Stegman和Mike Harsh在MIX 08上做了这分成2个部分的讲座， 讨论如何使用Silverlight建造应用。你可以使用上面的链接观看他们讲座的录像和下载相关讲义和示范例程。

• Creating Rich, Dynamic User Interfaces with Silverlight 2 Controls: Karen Corby在MIX 08上有个极棒的讲座，很好地解释了样式，控件模板，用户控件等等。你可以在这里运行和下载她完整的FlickR应用。

• 我的Silverlight入门讲座: 你可以下载我最近在亚利桑那做的“Silverlight 2入门”讲座的讲义和示范例程，请随意在你自己的讲座中重用这些讲义。

文档链接

• Silverlight 2 QuickStart Tutorials: 这些示范教程在上手Silverlight时会非常有用。

• Silverlight 2 Developer Poster: 下载和打印Silverlight 2开发者海报。

• Silverlight Control Source and Unit Tests: Shawn Burke提供了内置的Silverlight控件的源码以及相关单元测试的链接。

• MSDN Silverlight 2 Beta1 Online Documentation: 这个网页提供了正式的Silverlight 2文档的链接。你可以在这里下载离线版本。

教程和例程

• "How Do I?" with Silverlight: 这个链接连到了含有一堆Silverlight 2录像教程的网页。

• Hard Rock Memorabilia Sample: Vertigo Software公司的Scott Stanfield讨论三月份发布的使用Silverlight 2建造的很酷的Hard Rock Memorabilia网站。

• Using Deep Zoom with Silverlight 2: Jacek Ciereszko有一个很好的博客贴子，描述了如何使用Silverlight 2的 “Deep Zoom”功能实现跟Hard Rock例程类似的图像放大功能。

• Game Programming with Silverlight: Mike Snow正打造一个分成十一个部分的博客系列，讨论如何使用Silverlight开发在线游戏。

• Homepage "Link Cloud" application: Jeff Wilcox讨论他建造的一个很酷的标签云应用。

部署体验

• Providing a Great Silverlight Deployment Experience: Tim Heuer有个很好的贴子，讨论可以为你所用的技术来优化Silverlight安装体验。

• Using Silverlight 2 on a Production Web Server: Brad Abrams有个很好的贴子，讨论在把Silverlight .xap文件拷贝到IIS web服务器时需要注意的几件事情。

控件模板

• Creating a Custom Skin for Silverlight's Button Control: Matt Berseth的一个精彩好贴，讨论Silverlight控件的皮肤和样式功能。

• Writing a Templated Silverlight Control: Shawn Burke有个精彩贴子，详细描述了如何创建定制的Silverlight模板控件。

• Improving Access to Silverlight's Generic.xaml Resources (也阅读 这里的Part 2): David Anson有个很棒的工具，示范如何查看和提取内置Silverlight控件的默认XAML样式。

ListBox和ScrollViewer场景

• Ultimate ListBox and ScrollViewer Frequently Asked Questions Guide: David Anson，Silverlight ListBox和ScrollViewer控件的开发者，编篡了这个很棒的，关于所有这些控件的FAQ以及你可以使用它们的场景。

• Cool (wacky) uses of the ListBox and ScrollViewer controls: David Anson的又一篇精彩贴子，展示了数据和控件模板的灵活性。

DataGrid场景

• Using the Silverlight DataGrid and Defining Columns for a Silverlight DataGrid: Scott Morrison开始了一个精彩贴子系列，描述如何使用新的Silverlight 2 DataGrid控件（他是相关项目的主管，绝对精通！）

• Using Silverlight 2's DataGrid with WCF + LINQ to SQL: 这个15分钟的录像博客示范了如何在服务器上建造一个LINQ to SQL对象模型，然后用WCF将其发布，然后示范了如何建造一个使用了新的Silverlight DataGrid控件的Silverlight客户端，该客户端调用WCF服务获取LINQ to SQL数据，将其绑定到DataGrid上。

• Simple Editing of Web Service Data in a DataGrid: Mike Taulty有一篇好贴，展示如何在服务器上建造WCF服务，然后从Silverlight 2客户端使用它来获取数据，绑定到DataGrid，允许用户更新数据行，添加/删除数据行，然后使用 Silverlight 2 Beta1将数据保存到服务器上。

• Sorting with Silverlight 2's DataGrid Control: Silverlight 2 Beta1中的DataGrid控件还没有内置的列数据排序支持（将在Beta2中提供），但这并没有阻止Matt Berseth！ 在这个贴子里，他展示了如何使用一个定制的header列方法来实现排序。也看一下Matt的 这里的贴子，该文提供了一个DataGrid测试页面，展示了目前DataGrid的若干特性。

Web Services 和 Networking

• Web Services and Silverlight: 这个有用的贴子讨论了如何在Silverlight中使用web服务，并且提供了相关快速入门例程和文档的链接。

• Calling Web Services with Silverlight 2 (Part 1) and (Part 2): Tim Heuer的几篇精彩贴子，讨论如何使用Silverlight调用web服务。

Video场景

• Encoding Video for Microsoft Silverlight Delivery: Ben Waggoner在MIX 08上的讲座，讨论编码Silverlight录像的最佳实践。

Accessibility 和 508相容性

• Accessibility in Silverlight 2: Silverlight开发团队的Mark Rideout讨论 Silverlight 2 中的accessibility支持，以及如何使用Silverlight建造与section 508相容的accessible方案。

希望本文对你有所帮助，

Scott

Introduction

The Model View Controller (MVC) architectural pattern separates an application into three main components: the model, the view, and the controller. The ASP.NET MVC framework provides an alternative to the ASP.NET Web-forms pattern for creating MVC-based Web applications. The ASP.NET MVC framework is a lightweight, highly testable presentation framework that (as with Web-forms-based applications) is integrated with existing ASP.NET features, such as master pages and membership-based authentication. The MVC framework is defined in the System.Web.Mvc namespace and is a fundamental, supported part of the System.Web namespace.

MVC is a standard design pattern that many developers are familiar with. Some types of Web applications will benefit from the MVC framework. Others will continue to use traditional ASP.NET application pattern that is based on Web forms and postbacks. Other types of Web applications will combine the two approaches; neither approach precludes the other.

The MVC framework does not use view state or server-based forms. This makes it ideal for developers who want full control over the behavior of an application.

On the other hand, Web forms-based applications support an event model that preserves state over HTTP, which benefits line-of-business Web application development. The Web-forms-based application provides dozens of events that are supported in hundreds of server controls. MVC uses a Front Controller pattern that enables you design an application that completely separates the tasks of presentation, business logic, and data access, and that supports a rich routing infrastructure. Web forms applications use a page-controller pattern that adds functionality to individual pages. These two patterns can be mixed as needed.

The MVC components are as follows:

• Models - Model objects are the parts of your application that implement the domain logic. Often, model objects also retrieve and store model state in a database. For example, a Product object might retrieve information from a database, operate on it, and then write updated information back to a Products table in SQL Server.

  note

  In smaller applications, the model is often a conceptual separation rather than a physical one. For example, if the application only reads a data set and sends it to the view, the application does not have a physical model layer and associated classes. In that case, the data set takes on the role of a model object.

• Views - Views are the components that display the application's user interface (UI). Typically, this UI is created from the model data. An example would be an edit view of a Products table that displays text boxes, drop-down lists, and check boxes based on the current state of a Product object.

• Controllers - Controllers are the components that handle user interaction, manipulate the model, and ultimately select a view to render that displays UI. In an MVC application, the view only displays information; the controller handles and responds to user input and interaction. For example, the controller handles query-string values, and passes these values to the model, which in turn queries the database by using the values.

The MVC pattern helps you to create applications that separate the different aspects of the application (input logic, business logic, and UI logic), while providing a loose coupling between these elements. The pattern specifies where each kind of logic should exist in the application. The UI logic belongs in the view. Input logic belongs in the controller. Business logic belongs in the model. This separation helps you manage complexity when you build an application, because it enables you to focus on one aspect of the implementation at a time. For example, you can focus on the view without depending on the business logic.

In addition to managing complexity, the MVC pattern makes testing applications easier than testing a traditional ASP.NET Web application. For example, in a traditional ASP.NET Web application, a single class is used both to display output and to respond to user input. Writing automated tests for traditional ASP.NET applications can be complex, because to test an individual page, you must instantiate the page class, all its child controls, and additional dependent classes in the application. Because so many classes are instantiated to run the page, it can be hard to write tests that focus exclusively on individual portions of the application. Tests for traditional ASP.NET applications can therefore be more difficult to implement than test within an MVC application. Moreover, tests within a traditional ASP.NET application require a Web server. The MVC framework decouples the components and makes heavy use of interfaces, which makes it possible to test individual components in isolation from the rest of the framework.

The loose coupling between the three main components of an MVC application also promotes parallel development. For instance, one developer can work on the view, a second developer can work on the controller logic, and a third developer can focus on the business logic in the model.

Features of the ASP.NET MVC Framework

The ASP.NET MVC framework provides the following features:

• Separation of application tasks (input logic, business logic, and UI logic), testability, and test-driven development (TDD) by default. All core contracts within the MVC framework are interface-based and can be tested by using mock objects. You can unit-test the application without having to run the controllers in an ASP.NET process, which makes unit testing fast and flexible. You can use any unit-testing framework that is compatible with the .NET Framework.

• An extensible and pluggable framework. The components of the ASP.NET MVC framework are designed so that they can be easily replaced or customized. You can plug in your own view engine, URL routing policy, action-method parameter serialization, and other components. The ASP.NET MVC framework also supports using existing dependency injection and Inversion of Control (IOC) container models.

• A powerful URL-mapping component that lets you build applications that have comprehensible and searchable URLs. URLs do not have to include file-name extensions, and are designed to support URL naming patterns that work well for search engine optimization (SEO) and representational state transfer (REST) addressing. For example, you could map the /products/edit/4 URL to the Edit action of a ProductsController class in your project, or map the /Blogs/YourSite/10-10-2007/SomeTopic/ URL to a DisplayPost action of a BlogEngineController class. URLs do not have to reference file names.

• Support for using the markup in existing ASP.NET pages (.aspx files), user controls (.ascx files), and master pages (.master files) markup files as view templates. You can use existing ASP.NET features with the ASP.NET MVC framework, such as nested master pages, in-line expressions (<%= %>), declarative server controls, templates, data-binding, localization, and so on.

• Support for existing ASP.NET features. ASP.NET MVC lets you use features such as forms and Windows authentication, URL authorization, membership and roles, output and data caching, session and profile state management, health monitoring, configuration system, the provider architecture, and other areas of ASP.NET.

Background

In an ASP.NET Web Site, URLs typically map to files stored on disk (typically .aspx files). These .aspx files include code or markup that is processed in order to respond to the request.

The ASP.NET MVC framework maps URLs to server code in a different way. Instead of mapping URLs to ASP.NET pages or handlers, the framework maps URLs directly to controller classes. Controller classes handle incoming requests, such as user input and interactions, and also execute appropriate application and data logic based on user input. A controller class typically calls a separate view component that generates the HTML output as the response.

The ASP.NET MVC framework separates the model, view, and controller components. The model component maintains state by typically persisting data inside a database. The view component is selected by the controller and renders the appropriate UI. By default, the ASP.NET MVC framework uses the existing ASP.NET page (.aspx), master page (.master), and user control (.ascx) types for rendering to the browser. The controller component locates the appropriate action method in the controller, gets the values to use as the action method's arguments, handles all errors that might occur during the execution of the action, and renders the requested view. Each set of components exists in a separate subdirectory of an MVC Web application project.

URL Mapping

The ASP.NET MVC framework includes a URL-mapping engine that provides flexibility for mapping URLs to controller classes. You can use the mapping engine to define routing rules that the ASP.NET MVC framework uses to evaluate incoming URLs and to select a controller to execute. You can also have the routing engine automatically parse variables defined in the URL and have the ASP.NET MVC framework pass these to the controller as parameter arguments.

The MVC Framework and Postbacks

ASP.NET MVC framework does not use the traditional ASP.NET postback model for interactions with the server. Instead, all end-user interactions are routed to a controller class. This maintains separation between UI logic and business logic and helps testability. As a result, ASP.NET view state and ASP.NET page life-cycle events are not integrated with MVC-based views.

Creating an ASP.NET MVC Application

The ASP.NET MVC framework includes Visual Studio project templates that let you create Web applications that are structured to support the MVC pattern. The MVC Web Application template is used to create a new Web application that is configured with the subdirectories, templates, and configuration-file entries that are required for an ASP.NET MVC application.

By default, when you create a new Web application by using this template, Visual Studio creates a solution and adds two projects to the solution. The first project is a Web project where you can implement your application. The second project is a testing project that you can write unit tests for your MVC components.

You can use any unit-testing framework that is compatible with the .NET Framework to test ASP.NET MVC applications. Visual Studio 2008 Professional includes built-in testing project support for MSTest.

Understanding Web Application MVC Project Structure

When you create an ASP.NET MVC Web application project, MVC components are separated based on the following project folders:

• Views folder. The Views folder is the recommended location for views. The views use .aspx, .ascx, and .master files, as well as any other files that are related to rendering views. The Views directory contains a folder for each controller that is named with the controller prefix. When loading a view, by default the ASP.NET MVC framework will look for an .aspx file with the requested view name in the Views\controllerName folder. There is also a default directory named Common that does not correspond to any controller. This is a useful location to put master pages, scripts, CSS files, and other files that are used when rendering a view.

• Controller folder. The Controllers folder is the recommended location for controllers.

• Model folder. The Models folder is the recommended location for classes that represent the application model for your MVC Web application. Typically, this includes code that defines the logic for interaction with the data store.

• App_Data. The physical store for data. This folder has the same role as it does in Web-forms based ASP.NET Web applications.

In addition to the folders listed previously, a MVC Web application uses the following application elements:

• Global.asax and Global.asax.cs (or Global.asax.vb in Visual Basic). In Global.asax.cs, routes are initialized in the Application_Start method. The following example shows a typical Global.asax file that includes default routing logic.

  public class Global : System.Web.HttpApplication {
      protected void Application_Start(object sender, EventArgs e) {
      RouteTable.Routes.Add(new Route {
      Url = "[controller]/[action]/[id]",
      Defaults = new { action = "Index", id = (string)null },
      RouteHandler = typeof(MvcRouteHandler)
      });
      }
      }

• Configuration. The MVC Web application Web.config file registers HTTP handlers and HTTP modules. The httpHandlers section registers the MvcHandler class, which routes requests to the appropriate controller. The following example shows the httpHandlers section for an ASP.NET MVC application.

  <httpHandlers>
      <add verb="*" path="*.mvc" type="System.Web.Mvc.MvcHandler,
      System.Web.Extensions, Version=3.6.0.0, Culture=neutral,
      PublicKeyToken=31BF3856AD364E35"/>
      </httpHandlers>

  The httpModules section registers the UrlRoutingModule class, which parses the URL and routes requests to the appropriate handler. This entry enables the application to host MVC and non-MVC handlers in the same project. The following example shows the httpModules section for an ASP.NET MVC application.

  <httpModules>
      <add name="UrlRoutingModule"
      type="System.Web.Mvc.UrlRoutingModule,
      System.Web.Extensions, Version=3.6.0.0, Culture=neutral,
      PublicKeyToken=31BF3856AD364E35" />
      </httpModules>

When you create an MVC Web application project, the solution includes a Test project. You can create tests by using the MVC templates and create mock implementations of the intrinsic interfaces.

Understanding the MVC Project Execution Process

Requests to a Web site that is built by using the MVC framework are routed through an ASP.NET HTTP module and to an HTTP handler.

The module and handler are the entry points to the ASP.NET MVC framework and perform the following actions:

• Select the appropriate controller in an MVC Web application.

• Obtain a specific controller instance.

• Call the controller's Execute method.

The following table lists the stages of execution for an MVC Web project:

Example

The following code shows the default structure that is created by Visual Studio when you create a new MVC Web application.

This topic is ASP.NET 3.5 Extensions Preview pre-release documentation and is unsupported by Microsoft. Blank topics are included as placeholders and existing content is subject to change in future releases. To provide feedback or ask questions about the release, please go to the ASP.NET 3.5 Extensions Preview forums.

How to compress the ViewState of ASP.NET pages and save bandwidth.
http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx

Why do I need this?

publicint id;
publicstring userName;
void Page_Init(object sender, EventArgs e){
if (!string.IsNullOrEmpty(Request.QueryString["id"])){
id =int.Parse(Request.QueryString["id"]);
}
if(Request.Cookies["userName"] !=null &&
Request.Cookies["userName"].Value !=null){
userName = Request.Cookies["userName"].Value;
}
}

[PageProperty]
publicstring id;
[PageProperty(ReadFrom=DictionaryType.Cookie)]
publicstring userName;

Lets define what are we interested in reading

[flags]
public enum DictionaryType
{
QueryString = 1,
Form = 2,
Session = 4,
Context = 8,
Cookie = 16,
Header = 32
}

Next step will be to create Attribute class for our properties and fields.

1. Key which we need to pass to read data from dictionary, If user do not provide this key then we will assume that name of property/field is key.
2. Enumeration that defines dictionary to read data from which will default to query string.

publicclass PageProperty : Attribute {
private DictionaryType readFrom = DictionaryType.QueryString;
privatestring key;
publicstring Key {
get { return key; }
set { key = value; }
}
public DictionaryType ReadFrom {
get { return readFrom; }
set { readFrom = value; }
}
}

Once we have above class we can tag fields in our page with above attribute.

[PageProperty(ReadFrom = DictionaryType.Cookie)]
publicint userId;

Reading attributes using reflection and populating values.

1. We will use reflection to inspect page class to find all property or public fields with PageProperty Attribute. 
2. Next step will be to get key and DictionaryType.
3. And once we know source and target to populate and we will get information from appropriate dictionary and populate it.

publicstaticvoid Read(object pageObject)
{
// read for all fields.
      FieldInfo[] fields = (pageObject.GetType()).GetFields();
foreach (FieldInfo fieldInfo in fields)
{
object[] attributes
= fieldInfo.GetCustomAttributes(typeof(PageProperty), false);
if (attributes.Length > 0)
{
PageProperty pageProperty = attributes[0] as PageProperty;
string key = pageProperty.Key;
if (key == null) key = fieldInfo.Name;
object val = getValue(key, pageProperty.ReadFrom);
if (val !=null)
{
fieldInfo.SetValue(pageObject
, changeType(val, fieldInfo.FieldType));
}
}
…….

Retriving value from Dictionary.

[PageProperty(ReadFrom = DictionaryType.QueryString | DictionaryType.Cookie)]

privatestatic object getValue(string key, DictionaryType readFrom){
if ((readFrom & DictionaryType.QueryString)
== DictionaryType.QueryString &&
HttpContext.Current.Request.QueryString[key] !=null)
{
return HttpContext.Current.Request.QueryString[key];
} elseif ((readFrom & DictionaryType.Form)
== DictionaryType.Form &&
HttpContext.Current.Request.Form[key] !=null)
{
return HttpContext.Current.Request.Form[key];
}
…..

1. Drop Jigar.Web.PagePropertyReader.dll in to bin directory of your web project
2. In your Page class add following line in Pre_Init Event.
   PropertyReader.Read(this);
   Alternatively you can also create PageBase class by inheriting from System.Web.UI.Page and override PreInit event.
3. Finally in your page just create public property or field with PageProperty Attribute and you are done.

What about performance cost associated with reflection?

2、.NET Delegates: A C# Bedtime Story
An exploratory story of delegates and events for C# programmers told in the style of a bedtime story.
http://www.codeproject.com/csharp/delegate_bedtime.asp

3、Dependency Injection for Loose Coupling
This article describes the use of Dependency Injection, or Inversion-of-Control, to promote loose coupling and convenient unit testing.
http://www.codeproject.com/cs/design/DependencyInjection.asp
我的翻译：[2007-11-26]使用依赖注入解耦

Events and Delegates simplified
This article shows you how to design events for your classes.
http://www.codeproject.com/csharp/events.asp
我的翻译：[2007-11-19]事件和委托的简单说明

ASP.NET Best Practices for High Performance Applications
This article lists the techniques that you can use to maximize the performance of your ASP.NET applications. It provides common issues, design guidelines, and coding tips to build optimal and robust solutions.
http://www.codeproject.com/aspnet/ASPNET_Best_Practices.asp

IMPORTANT: After the Beta 2 installation has finished, you should run this script to ensure that the installation of .NET Framework 3.5 Beta 2 will not affect the development of ASP.NET AJAX 1.0 applications.

• Download trivial example of MVP - 14.7 Kb
• Download simple Event-Handling MVP - 16.0 Kb
• Download sample MVP Enterprise Solution - 2605.2 Kb

Author's note added October 15, 2007 - Suggestion of MVC over MVP

As we progress as developers, we strive to seek out the "best" way to perform our craft. The chosen methods to attain this lofty goal always bring with them a number of developmental trade-offs. Some techniques may simplify the code but lessen fine grained control while others enable greater power while introducing complexity. Model-View-Presenter with ASP.NET is a wonderful example of the latter. MVP aims to facilitate test-driven development of ASP.NET applications with the unfortunate introduction of added complexity. So while developers will be more confient in the quality of their product, MVP hinders their ability to easily maintain code. Yes, the tests will (hopefully) inform the developer that a bug has been introduced, but the inherent complexity of MVP makes it difficult for later team members to become comfortable with the code base and maintain it as project development continues.

Fortunately, as time progresses quickly in our field, resources and tools become available which enhance our ability to write powerful applications while simplifying the coding process itself. The introduction of NHibernate, for example, eliminated vast amounts of data-access code while still providing powerful facilities for managing transactions and dynamically querying data. Castle MonoRail (and Microsoft's upcoming spin-off of this framework) now does for writing testable and maintainable .NET web applications what NHibernate (and the upcoming LINQ to Entities) did for ADO.NET. This is not to say that the previous techniques were necessarily wrong, but that they were only applicable considering the developer's toolset that was available at the time of selection.

In adapting to the evolution of our field, it is important for developers to note when an accepted technique is no longer valuable in light of current alternatives. Specifically, MVP was a very powerful technique for writing ground-up, test-driven ASP.NET applications but is no longer a strong candidate for consideration when compared to the time saving benefits and simplicity of Castle MonoRail and Microsoft's upcoming MVC framework. Oddly, it is sometimes difficult to "give up" on something that worked perfectly fine before, but that's the nature of our business ... one tenet that's not likely to change anytime soon.

Of this article, I believe it to be of continued value to those maintaining legacy applications built upon MVP and for those interested in learning a solid domain driven architecture which is discussed further below and in detail in another post.

In summary, although I still believe that MVP is the best technique for developing ground-up ASP.NET solutions, I believe that there are off-the-shelf frameworks which make the entire job a heck of a lot simpler.

Introduction

After years of maintaining thousands of lines of ASP spaghetti code, Microsoft has finally given us a first class web development platform: ASP.NET. ASP.NET instantly brought a basic separation of concerns between presentation and business logic by introducing the code-behind page. Although introduced with good intentions and perfect for basic applications, the code-behind still lacks in a number of aspects when developing enterprise web applications:

• The code-behind invites melding the layers of presentation, business logic and data-access code. This occurs because the code-behind page often serves the role of an event handler, a workflow controller, a mediator between presentation and business rules, and a mediator between presentation and data-access code. Giving the code-behind this many responsibilities often leads to unmanageable code. In an enterprise application, a principle of good design is to maintain proper separation of concerns among the tiers and to keep the code-behind as clean as possible. With Model-View-Presenter, we'll see that the code-behind is greatly simplified and kept strictly to managing presentation details.
• Another drawback to the code-behind model is that it is difficult to reuse presentation logic between code-behind pages without enlisting helper/utility classes that consolidate the duplicated code. Obviously, there are times that this provides an adequate solution. However, it often leads to incohesive classes that act more like ASP includes than first class objects. With proper design, every class should be cohesive and have a clear purpose. A class named ContainsDuplicatePresentationCodeBetweenThisAndThat.cs usually doesn't qualify.
• Finally, it becomes nearly prohibitive to properly unit test code-behind pages as they are inseparably bound to the presentation. Options such as NUnitAsp may be used, but they are time consuming to implement and difficult to maintain. They also slow down unit-test performance considerably, where unit tests should always be blazingly fast.

Various techniques may be employed to promote a better separation of concerns from the code-behind pages. For example, the Castle MonoRail project attempts to emulate some of the benefits of Ruby-On-Rails but abandons the ASP.NET event model in the process. Maverick.NET is a framework that optionally supports the ASP.NET event model but leaves the code-behind as the controller in the process. Ideally, a solution should be employed that leverages the ASP.NET event model while still allowing the code-behind to be as simple as possible. The Model-View-Presenter pattern does just that without relying on a third party framework to facilitate this goal.

Model-View-Presenter

Model-View-Presenter (MVP) is a variation of the Model-View-Controller (MVC) pattern but specifically geared towards a page event model such as ASP.NET. For a bit of history, MVP was originally used as the framework of choice behind Dolphin Smalltalk. The primary differentiator of MVP is that the Presenter implements an Observer design of MVC but the basic ideas of MVC remain the same: the model stores the data, the view shows a representation of the model, and the presenter coordinates communications between the layers. MVP implements an Observer approach with respect to the fact that the Presenter interprets events and performs logic necessary to map those events to the proper commands to manipulate the model. For more reading on MVC vs. MVP, take a look at Darron Schall's concise entry on the subject. What follows is a detailed examination of MVP in the form of three example projects.

Author's note: Martin Fowler has suggested that MVP be split between two "new" patterns called Supervising Controller and Passive View. Go here for a very short synopsis of the split. The content described herein is more consistent with Supervising Controller as the View is aware of the Model.

A most trivial example

• Download trivial example of MVP - 14.7 Kb

In this example project, the client wants a page that shows the current time. Thank goodness they started us off with something easy! The ASPX page that will show the time is the "View." The "Presenter" is responsible for determining the current time -- i.e. the "Model" -- and giving the Model to the View. As always, we start with a unit test:

Collapse

[TestFixture]
public class CurrentTimePresenterTests
{
[Test]
public void TestInitView()
{
MockCurrentTimeView view = new MockCurrentTimeView();
CurrentTimePresenter presenter = new CurrentTimePresenter(view);
presenter.InitView();
Assert.IsTrue(view.CurrentTime > DateTime.MinValue);
}
private class MockCurrentTimeView : ICurrentTimeView
{
public DateTime CurrentTime
{
set { currentTime = value; }
// This getter won't be required by ICurrentTimeView,
// but it allows us to unit test its value.
get { return currentTime; }
}
private DateTime currentTime = DateTime.MinValue;
}
}

The above unit test, along with the diagram, describes the elements of the MVP relationship. The very first line creates an instance of MockCurrentTimeView. As seen with this unit test, all of the Presenter logic can be unit tested without having an ASPX page, i.e. the View. All that is needed is an object that implements the View interface; accordingly, a mock view is created that stands in place of the "real" view.

The next line creates an instance of the Presenter, passing an object that implements ICurrentTimeView via its constructor. In this way, the Presenter can now manipulate the View. As seen in the diagram, the Presenter only talks to a View interface. It does not work with a concrete implementation directly. This allows multiple Views, implementing the same View interface, to be used by the same Presenter.

Finally, the Presenter is asked to InitView(). This method will get the current time and pass it to the View via a public property exposed by ICurrentTimeView. A unit-test assertion is then made that the CurrentTime on the view should now be greater than its initial value. A more detailed assertion could certainly be made if needed.

All that needs to be done now is to get the unit test to compile and pass!

ICurrentTimeView.cs: the View interface

As a first step towards getting the unit test to compile, ICurrentTimeView.cs should be created. This View interface will provide the conduit of communication between the Presenter and the View. In the situation at hand, the View interface needs to expose a public property that the Presenter can use to pass the current time, the Model, to the View.

public interface ICurrentTimeView
{
DateTime CurrentTime { set; }
}

The View only needs a setter for the current time since it just needs to show the Model, but providing a getter allows CurrentTime to be checked within the unit test. So instead of adding a getter to the interface, it can be added to MockCurrentTimeView and need not be defined in the interface at all. In this way, the exposed properties of the View can be unit tested without forcing extraneous setters/getters to be defined in the View Interface. The described unit test above shows this technique.

CurrentTimePresenter.cs: the Presenter

The presenter will handle the logic of communicating with the Model and passing Model values to the View. The Presenter, needed to make the unit test compile and pass, is as follows.

public class CurrentTimePresenter
{
public CurrentTimePresenter(ICurrentTimeView view)
{
if (view == null)
throw new ArgumentNullException("view may not be null");
this.view = view;
}
public void InitView()
{
view.CurrentTime = DateTime.Now;
}
private ICurrentTimeView view;
}

Once the above items have been developed -- the unit test, the mock view, the view and the presenter -- the unit test will now compile and pass successfully. The next step is creating an ASPX page to act as the real View. As a quick side, take note of the ArgumentNullException check. This is a technique known as "Design by Contract." Putting checks like this all over your code will greatly cut down on tracking down bugs. For more information about Design by Contract, see this article and this article.

ShowMeTheTime.aspx: the View

The actual View needs to do the following:

1. The ASPX page needs to provide a means for displaying the current time. As shown below, a simple label will be used for display.
2. The code-behind must implement ICurrentTimeView.
3. The code-behind needs to create the Presenter, passing itself to the Presenter's constructor.
4. After creating the Presenter, InitView() needs to be called to complete the MVP cycle.

The ASPX page

...
<asp:Label id="lblCurrentTime" runat="server" />
...

The ASPX code-behind page

public partial class ShowMeTheTime : Page, ICurrentTimeView
{
protected void Page_Load(object sender, EventArgs e)
{
CurrentTimePresenter presenter = new CurrentTimePresenter(this);
presenter.InitView();
}
public DateTime CurrentTime
{
set { lblCurrentTime.Text = value.ToString(); }
}
}

Is that it?

In a word, yes. But there is much more to the story! A drawback to the above example is that MVP seems like a lot of work for such little gain. We've gone from having one ASPX page to having a Presenter class, a View interface and a unit testing class. The gain has been the ability to unit test the Presenter, i.e. the ability to conveniently unit test code that would normally be found in the code-behind page. As is the case with trivial examples, the advantages of MVP shine when developing and maintaining enterprise web applications, not when writing "hello world"-like samples. The following topics elaborate the usage of MVP within an enterprise, ASP.NET application.

MVP within enterprise ASP.NET applications

• Encapsulating Views with user controls: This topic discusses the MVP approach of User Control-as-View.
• Event handling with MVP: This topic discusses passing events to the Presenter along with considerations of page validation, IsPostBack and sending messages back to the View.
• Page redirects with MVP & PageMethods: This topic includes how to handle page redirects using PageMethods with a User Control-as-View architecture.
• Presentation security with MVP: This topic discusses handling basic security constraints for hiding/showing sections of a View.
• Application architecture with MVP (Advanced): The whole shebang! This topic puts forth a recommended approach to architecting an MVP, enterprise application complete with an NHibernate data-access layer.

I. Encapsulating Views with user controls

In the previous, simple example, the ASPX page itself acted as the View. Treating the ASPX in this way was sufficient in that the page had only one simple purpose - to show the current time. But in more representative projects, it is often the case that a single page will have one or more sections of functionality whether they be WebParts, user controls, etc. In these more typical of enterprise applications, it is important to keep functionality logically separated and to make it easy to move/replicate functionality from one area to another. With MVP, user controls can be used to encapsulate Views while the ASPX pages act as "View Initializers" and page redirectors. Extending the previous example, we need only modify the ASPX page to implement the change. This is another benefit of MVP; many changes can be made to the View layer without having to modify the Presenter and Model layers.

ShowMeTheTime.aspx redux: the View initializer

With this new approach, using user controls as the view, ShowMeTheTime.aspx is now responsible for the following:

1. The ASPX page needs to declare the user control which will implement ICurrentTimeView.
2. The ASPX code-behind needs to create the Presenter, passing the user control to the Presenter's constructor.
3. After giving the View to the Presenter, the ASPX needs to call InitView() to complete the MVP cycle.

The ASPX page

...
<%@ Register TagPrefix="mvpProject"
TagName="CurrentTimeView" Src="./Views/CurrentTimeView.ascx" %>
<mvpProject:CurrentTimeView id="currentTimeView" runat="server" />
...

The ASPX code-behind page

public partial class ShowMeTheTime : Page
// No longer implements ICurrentTimeView
{
protected void Page_Load(object sender, EventArgs e)
{
InitCurrentTimeView();
}
private void InitCurrentTimeView()
{
CurrentTimePresenter presenter =
new CurrentTimePresenter(currentTimeView);
presenter.InitView();
}
}

CurrentTimeView.ascx: the user control-as-view

The user control now represents the bare-bones View. It is as "dumb" as it can be - which is exactly how we want a View to be.

The ASCX page

...
<asp:Label id="lblCurrentTime" runat="server" />
...

The ASCX code-behind page

public partial class Views_CurrentTimeView : UserControl, ICurrentTimeView
{
public DateTime CurrentTime
{
set { lblCurrentTime.Text = value.ToString(); }
}
}

Pros and cons of the user Control-as-View approach

Obviously, the primary drawback to the User Control-as-View approach to MVP is that it adds yet another piece to the equation. The entire MVP relationship is now made up of: unit test, presenter, view interface, view implementation (the user control) and the view initializer (the ASPX page). Adding this additional layer of indirection adds to the overall complexity of the design. The benefits of the user control-as-View approach include:

• The View can be easily moved from one ASPX page to another. This happens regularly in a mid to large sized web application.
• The View can be easily reused by different ASPX pages without duplicating much code at all.
• The View can be initialized differently by different ASPX pages. For example, a user control could be written that displays a listing of projects. From the reporting section of the site, the user may view and filter all the projects available. From another section of the site, the user may only view a subset of the projects and not have the ability to run filters. In implementation, the same View can be passed to the same presenter, but then each ASPX page, in its respective section of the site, would call a different method on the Presenter to initialize the View in a unique way.
• Additional Views can be added to the ASPX page without adding much additional, coding overhead. Simply include the new user control-as-view into the ASPX page and link it to its Presenter in the code-behind. Placing multiple sections of functionality within the same ASPX page, without using user controls, quickly creates a maintenance headache.

II. Event handling with MVP

• Download simple event-handling MVP - 16.0 Kb

The previous example described, essentially, a one-way round of communications between a Presenter and its View. The Presenter communicated with the Model and delivered it to the View. In most situations, events occur which need to be handed off to the Presenter for action. Furthermore, some events depend on whether or not a form was valid and whether or not IsPostBack had occurred. For example, there are some actions, such as data-binding, that may not be done when IsPostBack.

Disclaimer: Page.IsPostBack and Page.IsValid are web specific keywords. Therefore the following may make the presenter layer, as described, slightly invalid in non-web environments. However, with minor modifications it will work fine for WebForms, WinForms or mobile applications. In any case, the theory is the same but I welcome suggestions for making the presenter layer transferable to any .NET environment.

A simple event handling sequence

Continuing with the earlier example, assume that requirements now dictate that the user may enter a number of days to be added to the current time. The time shown in the View should then be updated to show the current time plus the number of days supplied by the user, assuming the user provided valid inputs. When not IsPostBack, the current time should be displayed. When IsPostBack, the Presenter should respond to the event accordingly. The sequence diagram below shows what occurs upon the user's initial request (top half of diagram) and what happens when the user clicks the "Add Days" button (bottom half of diagram). A more thorough review of the sequence follows the diagram.

A) User Control-as-View created

This step simply represents the inline user control declaration found in the ASPX page. During page initialization, the user control gets created. It's included on the diagram to emphasize the fact that the user control implements ICurrentTimeView. During Page_Load, the ASPX code-behind then creates an instance of the Presenter, passing the User Control-as-View via its constructor. So far, everything looks identical to what was described in the section "Encapsulating Views with User Controls."

B) Presenter attached to View

In order for an event to be passed from the user control, the View, to the Presenter, it must have a reference to an instance of CurrentTimePresenter. To do this, the View Initializer, ShowMeTheTime.aspx, passes the Presenter to the View for later use. Contrary to initial reaction, this does not cause a bi-directional dependency between the Presenter and the View. Instead, the Presenter depends on the View interface and the View implementation depends on the Presenter to pass events off to. To see how it all works, let's take a step back to look at how all the pieces are now implemented.

ICurrentTimeView.cs: the View interface

public interface ICurrentTimeView
{
DateTime CurrentTime { set; }
string Message { set; }
void AttachPresenter(CurrentTimePresenter presenter);
}

CurrentTimePresenter.cs: the Presenter

Collapse

public class CurrentTimePresenter
{
public CurrentTimePresenter(ICurrentTimeView view)
{
if (view == null)
throw new ArgumentNullException("view may not be null");
this.view = view;
}
public void InitView(bool isPostBack)
{
if (! isPostBack)
{
view.CurrentTime = DateTime.Now;
}
}
public void AddDays(string daysUnparsed, bool isPageValid)
{
if (isPageValid)
{
view.CurrentTime =
DateTime.Now.AddDays(double.Parse(daysUnparsed));
}
else
{
view.Message = "Bad inputs...no updated date for you!";
}
}
private ICurrentTimeView view;
}

CurrentTimeView.ascx: the View

The ASCX page

...
<asp:Label id="lblMessage" runat="server" /><br />
<asp:Label id="lblCurrentTime" runat="server" /><br />
<br />
<asp:TextBox id="txtNumberOfDays" runat="server" />
<asp:RequiredFieldValidator ControlToValidate="txtNumberOfDays" runat="server"
ErrorMessage="Number of days is required" ValidationGroup="AddDays" />
<asp:CompareValidator
ControlToValidate="txtNumberOfDays" runat="server"
Operator="DataTypeCheck" Type="Double" ValidationGroup="AddDays"
ErrorMessage="Number of days must be numeric" /><br />
<br />
<asp:Button id="btnAddDays" Text="Add Days" runat="server"
OnClick="btnAddDays_OnClick" ValidationGroup="AddDays" />
...

The ASCX code-behind page

Collapse

public partial class Views_CurrentTimeView : UserControl, ICurrentTimeView
{
public void AttachPresenter(CurrentTimePresenter presenter)
{
if (presenter == null)
throw new ArgumentNullException("presenter may not be null");
this.presenter = presenter;
}
public string Message
{
set { lblMessage.Text = value; }
}
public DateTime CurrentTime
{
set { lblCurrentTime.Text = value.ToString(); }
}
protected void btnAddDays_OnClick(object sender, EventArgs e)
{
if (presenter == null)
throw new FieldAccessException("presenter has" +
" not yet been initialized");
presenter.AddDays(txtNumberOfDays.Text, Page.IsValid);
}
private CurrentTimePresenter presenter;
}

ShowMeTheTime.aspx: the View initializer

The ASPX page

...
<%@ Register TagPrefix="mvpProject"
TagName="CurrentTimeView" Src="./Views/CurrentTimeView.ascx" %>
<mvpProject:CurrentTimeView id="currentTimeView" runat="server" />
...

The ASPX code-behind page

public partial class ShowMeTheTime : Page
// No longer implements ICurrentTimeView
{
protected void Page_Load(object sender, EventArgs e)
{
InitCurrentTimeView();
}
private void InitCurrentTimeView()
{
CurrentTimePresenter presenter =
new CurrentTimePresenter(currentTimeView);
currentTimeView.AttachPresenter(presenter);
presenter.InitView(Page.IsPostBack);
}
}

C) Presenter InitView

As defined in the requirements, the Presenter should only show the current time if not IsPostBack. The important action to note is that the Presenter should decide what to do according to IsPostBack. It should not be the job of the ASPX code-behind to make this decision. As seen in the code above, the ASPX code-behind does no check for IsPostBack. It simply passes the value to the Presenter to determine what action to take.

This may lead to the question, "But what happens if another user control-as-view caused the post-back to occur?" In the scenario at hand, the current time would remain in the view state of the label and be displayed again after post back. This may be OK depending on the needs of the client. In general, it's a good question to ask of any Presenter: what impact will a post-back from another user control have on the View? In fact, it's a good question to ask even if you're not using MVP. There may be actions that should always occur, regardless of IsPostBack, while other initialization steps may be bypassed. View state settings obviously have a large impact on this decision, as well.

When not IsPostBack, as shown in the diagram, the Presenter then sets the CurrentTime of the view via its interface. Sequence diagram purists may raise the point that the diagram implies two messages are being sent -- one from CurrentTimePresenter to ICurrentTimeView and then one from ICurrentTimeView to CurrentTimeView.ascx -- when in fact only one is being sent from CurrentTimePresenter to CurrentTimeView.ascx, polymorphically. The interface "middleman" is included to emphasize that the Presenter does not depend on the concrete View directly.

D) Presenter InitView after IsPostBack

In the preceding steps, the user made the HTTP request, the Presenter set the current time on the View, and the HTTP response was delivered to the user. Now, the user clicks the "Add Days" button, which causes a post-back. Everything occurs as before until InitView is called on the Presenter. At this point, the Presenter tests for IsPostBack and does not set the CurrentTime on the View.

E) Button click handled by user control

After the Page_Load of the ASPX page has occurred, the OnClick event is then raised to the user control. The View should not handle the event itself; it should immediately pass the event on to the Presenter for action. By looking at the code-behind of the user control, you can see that it makes sure it has been given a valid presenter -- more "Design by Contract" -- and then hands the command off to the Presenter. The Presenter then verifies that the page was valid and sets the time or error message accordingly.

The above has been an exhaustive analysis of a complete MVP cycle with event handling. Once you get the hang of MVP, it takes very little time to get all the pieces in place. Remember to always begin with a unit test and let the unit tests drive the development. The unit tests not only help ensure that the MVP pieces are working correctly, they also serve as the point for defining the communications protocol among the pieces. A Visual Studio code snippet for an MVP unit test can be found in Appendix B. We'll now take a look at look at handling page redirection.

III. Page redirects with MVP & PageMethods

In developing enterprise application, application flow is always a concern. Who's going to take care of page redirects? Should action redirects be stored in a configurable XML file? Should a third party tool such as Maverick.NET or Spring.NET handle page flow? Personally, I like to keep the page redirects as close to the action as possible. In other words, I feel that storing action/redirects in an external XML file leads to further indirection that can be tedious to understand and maintain. As if we don't have enough to worry about already! On the other hand, hard-coded redirects in the ASPX code-behind are fragile, tedious to parse and not strongly typed. To solve this problem, the free download PageMethods allows you to have strongly typed redirects. So instead of writing Response.Redirect("../Project/ShowProjectSummary?projectId=" + projectId.ToString() + "&userId=" + userId.ToString()), PageMethods provides a strongly typed redirect that would look more like Response.Redirect(MyPageMethods.ShowProjectSummary.ShowSummaryFor(projectId, userId)). The redirect is strongly typed and, therefore, checked at compile time.

An MVP related question concerning page redirects remains: who should be responsible for making a redirect and how should the redirect be initiated? I believe there are a number of valid answers to this question but will propose a solution that I've found to be rather successful. Add one event to the Presenter for each outcome that is possible. For example, assume a website is made up of two pages. The first page lists a number of projects; the second page, reached by clicking "Edit" next to one of the project names, allows the user to update the project's name. After updating the project name, the user should be redirected to the project listing page again. To implement this, the Presenter should raise an event showing that the project name was successfully changed and then the View Initializer, the ASPX page, should execute the appropriate redirect. Note that the following is illustrative and not associated with the "current time" example discussed thus far.

Presenter

...
public event EventHandler ProjectUpdated;
public void UpdateProjectNameWith(string newName)
{
...
if (everythingWentSuccessfully)
{
ProjectUpdated(this, null);
}
else
{
view.Message = "That name already exists.  Please provide a new one!";
}
}
...

ASPX code-behind

...
protected void Page_Load(object sender, EventArgs e)
{
EditProjectPresenter presenter =
new EditProjectPresenter(editProjectView);
presenter.ProjectUpdated += new EventHandler(HandleProjectUpdated);
presenter.InitView();
}
private void HandleProjectUpdated(object sender, EventArgs e)
{
Response.Redirect(
MyPageMethods.ShowProjectSummary.Show(projectId, userId));
}
...

Taking this approach keeps page redirection out of the Presenter and out of the View. As a rule of thumb, the Presenter should never require a reference to System.Web. Furthermore, disassociating redirects from the View -- i.e. the user control -- and allows the View to be used again by other View Initializers, i.e. other ASPX pages. At the same time, it leaves application flow up to each individual View Initializer. This is the greatest benefit of using an event based model of redirection with User Control-as-View MVP.

IV. Presentation security with MVP

Oftentimes, a column, button, table or whatever should be shown/hidden based on the permissions of the user viewing the website. Likewise, an item may be hidden when a View is included in one View Initializer vs. being included in different View Initializer. The security should be determined by the Presenter but the View should handle how that decision should be implemented. Picking up again with the "current time" example, assume that the client only wants the "Add Days" section to be available for users on even days, e.g. 2, 4, 6. The client likes to keep the users guessing! The View could encapsulate this area within a panel, as follows:

...
<asp:Panel id="pnlAddDays" runat="server" visible="false">
<asp:TextBox id="txtNumberOfDays" runat="server" />
<asp:RequiredFieldValidator
ControlToValidate="txtNumberOfDays" runat="server"
ErrorMessage="Number of days is required" ValidationGroup="AddDays" />
<asp:CompareValidator ControlToValidate="txtNumberOfDays" runat="server"
Operator="DataTypeCheck" Type="Double" ValidationGroup="AddDays"
ErrorMessage="Number of days must be numeric" /><br />
<br />
<asp:Button id="btnAddDays" Text="Add Days" runat="server"
OnClick="btnAddDays_OnClick" ValidationGroup="AddDays" />
</asp:Panel>
...

Note that the panel's visibility is pessimistically set to false. Although it would not make much difference in this case, it is better to be pessimistic about showing secure elements than the other way around. The code-behind of the View would then expose a setter to show/hide the panel:

...
public bool EnableAddDaysCapabilities
{
set { pnlAddDays.Visible = value; }
}
...

Note that the View does not expose the panel directly. This is intentionally done for two reasons: 1) exposing the panel directly would require that the Presenter have a reference to System.Web, something we want to avoid, and 2) exposing the panel ties the Presenter to an "implementation detail" of the View. The more a Presenter is tied to how a View is implemented, the less likely it will be reusable with other Views. As with other OOP scenarios, the pros and cons of exposing implementation details of the View need to be weighed against looser coupling to the Presenter.

Finally, during InitView, the Presenter checks if the user should be allowed to use the add-days functionality and sets the permission on the View accordingly:

...
public void InitView()
{
view.EnableAddDaysCapabilities = (DateTime.Now.Day % 2 == 0);
}
...

This simple example can be extended to a varied number of scenarios including security checks. Note that this is not a replacement for built-in .NET security, but it serves to augment it for finer control.

V. Application architecture with MVP

• Download sample MVP Enterprise Solution

Finally! How does all of this fit together in a data-driven, enterprise application? "Enterprise application," in this instance, is an application that has logically separated tiers including presentation, domain and data-access layers. The following graph shows an overview of a fully architected solution with discussion following.

Each raised box represents a distinct specialization of the application. Each gray box then represents a separate physical assembly, e.g. MyProject.Web.dll, MyProject.Presenters.dll, MyProject.Core.dll. The arrows represent dependencies. For example, the .Web assembly depends on the .Presenters and .Core assemblies. The assemblies avoid bi-directional dependency using the techniques Dependency Inversion and Dependency Injection. My preferred means of Dependency Injection -- "DI" in the above graph -- to the View Initializers is via the Castle Windsor project. The data layer then uses the ORM framework, NHibernate, for communicating with the database.

For a primer on Dependency Injection, read the CodeProject article entitled "Dependency Injection for Loose Coupling." Additionally, for a complete overview of this architecture, sans the .Presenters layer and Castle Windsor integration, read the CodeProject article entitled "NHibernate Best Practices with ASP.NET." This article also describes how to set up and run the sample application. Yes, these are both shameless plugs for other articles I have written, but both are required reading to fully appreciate the sample solution. Please feel free to raise any questions concerning the architecture.

In summary

At first glance, implementing MVP looks like a lot of extra work. In fact, it will slow development a bit during the initial stages of development. However, after using it in all stages of enterprise application development, the long-term benefits of using the approach far outweigh the initial feelings of discomfort with the pattern. MVP will greatly extend your ability to unit test and keep code more maintainable throughout the lifetime of the project, especially during the maintenance phase. When it comes right down to it, I'm not suggesting that you use MVP on all your enterprise ASP.NET projects, just the projects that you want to work! ;) In all seriousness, MVP is not appropriate in all situations. An application's architecture should fit the task at hand and complexity should not be added unless warranted. Obviously, MVP and User-Control-as-View MVP are just two architectural options among many. However, if used appropriately, MVP allows you to be confident in your presentation logic by making most of the code that would have been in a code-behind, testable and maintainable.

Appendix A: additional references

• Martin Fowler's soon-to-be-published overview of MVP
• The humble dialog box
• MVC vs. MVP
• A thank you goes out to Jeffrey Palermo for inspiring the above architectural diagram

Appendix B: MVP unit test code-snippet for Visual Studio 2005

With a default VS 2005 install location, copy the following contents to "MVP Test Init.snippet" under "C:\Program Files\Microsoft Visual Studio 8\VC#\Snippets\1033\Visual C#".

Collapse

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets
xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet Format="1.0.0">
<Header>
<Title>MVP Test Init</Title>
<Shortcut>mvpTestInit</Shortcut>
<Description>Code snippet for creating an initial
unit test for a new MVP setup.</Description>
<Author>Billy McCafferty</Author>
<SnippetTypes>
<SnippetType>Expansion</SnippetType>
</SnippetTypes>
</Header>
<Snippet>
<Declarations>
<Literal>
<ID>viewInterface</ID>
<ToolTip>Name of the view interface</ToolTip>
<Default>IView</Default>
</Literal>
<Literal>
<ID>presenter</ID>
<ToolTip>Name of the presenter class</ToolTip>
<Default>Presenter</Default>
</Literal>
<Literal>
<ID>mockView</ID>
<ToolTip>Name of the mock view
used in the unit test</ToolTip>
<Default>MockView</Default>
</Literal>
</Declarations>
<Code Language="csharp">
<![CDATA[        [Test]
public void TestInitView()
{
$viewInterface$ view = new $mockView$();
$presenter$ presenter = new $presenter$(view);
view.AttachPresenter(presenter);
presenter.InitView();
}
private class $mockView$ : $viewInterface$
{
public void AttachPresenter($presenter$ presenter)
{
}
}
$end$]]>
</Code>
</Snippet>
</CodeSnippet>
</CodeSnippets>

History

• 2006.07.02 - Initial posting
• 2007.04.18 - Added lessons learned over the past year to top of article
• 2007.07.10 - Article edited and moved to the main CodeProject.com article base

Posted by darron at June 9, 2004 12:44 PM

<configSections>

<section name="MicrosoftWebControls" type="System.Configuration.NameValueSectionHandler, System, System.Configuration.NameValueSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

</configSections>

<MicrosoftWebControls>

<add key="CommonFiles" value="/webctrl_client/1_0" />

</MicrosoftWebControls>

可以修改调用树的htc的位置

把以上配置中的
/webctrl_client/1_0
改为
网址全称
http://localhost/webctrl_client/1_0