写自己的ASP.NET MVC框架（上）

写了几篇细说之后，今天打算换换口味，还是来写代码吧。 所以，这次博客将以实际的代码来展示在ASP.NET平台上开发自己的框架，我希望也能让您发现这并不是件难事。

我在前面的博客【用Asp.net写自己的服务框架】中， 发布了一个用ASP.NET写的服务框架，那个框架我目前仍在使用中。近来，由于时常也会有人问我一些关于ASP.NET MVC的话题， 因此，就想再写个自己的MVC框架出来，一方面可以留给自己使用，另外也可以谈谈MVC，尤其可以展示一下在ASP.NET下写框架的乐趣。

我之所以将写框架看成是件有乐趣的事，是因为：在写框架的过程中会接触许多的技术细节。
比如：
1. 为了支持Session需要了解管线过程以及支持Session工作的原理。
2. 在HttpHandler的映射过程中，HttpHandlerFactory的使用会让设计很灵活。
3. 反射可以让我们轻松地根据一个URL去寻找匹配的Action以及为Action准备传入参数。
4. 为了便于测试Action，如何有效的封装框架的功能（这里有许多ASP.NET的技术细节）。
5. 如何设计让框架更灵活更强大。

在开始今天的博客之前，我想有必要说说我的框架的规模：
如果说ASP.NET WebForm是个复杂框架，ASP.NET MVC是个轻量级框架的话，那么，我的MVC框架将只是个微量级的框架。
但这个微量级的框架却可以提供许多实用的功能（因为我没有引入一些与MVC无关的东西），而且完全遵守MVC的思想而设计。
由于我的框架规模实在太小，因此，有些地方的确是不够完善，但我认为在大多数情况下是够用的。

时常见到有人在问：到底选择WebForm还是MVC ？
其实我认为最好是二个都选吧。然后，你去发现它们的优点与缺点，最后，当你觉得它们都不爽时，还是写自己的框架吧。

我来说说我这样选择的理由：任何东西都有它们的优点，这很正常，所以二个都选就能发现更多的优点， 发现优点的过程其实也是自己进步的过程。当然它们也有缺点，发现那些缺点，你自然会想办法去避开， 其实这也是个进步的过程。因此，在你吸收优点以及避开缺点的过程中，会感觉它们不再完美（因为自己在进步）， 再到后来，你会怎么选择，我就不知道了，那就是你自己的事了。 而我选择了另一条路：写自己的ASP.NET MVC框架。

在比较各类框架之前，我想有必要先来总结一下：现在能用ASP.NET开发哪些类型的网站？ 由于ASP.NET与WCF这类纯服务性质的框架不同，我们主要还是用它来开发一些可与用户交互的界面程序。 因此，今天的分类将重要讨论这些界面（UI）的开发方式。

我认为目前的ASP.NET能支持开发三种类型的网站：
1. 以服务端为中心的网站：所有页面的生成以及交互的逻辑全部服务端来完成，服务端甚至能生成必要的JS代码。
2. 门户类网站：服务端只负责页面的第一次呈现，用户的交互以及表单的提交全部采用AJAX的方式完成。
3. 纯AJAX网站：服务端基本上不参与UI的处理，只负责处理数据，UI在客户端由JavaScript来生成并控制提交。

【以服务端为中心的网站】，这类网站有个非常明显的特点，至少在开发上表现地非常明显： 服务端要做的事情很多，HTML的生成, 简单的JS交互，客户端验证，等等，全由服务端来处理。 在开发这类网站时，由于工作全在服务端，因此如果我们使用ASP.NET开发，自然地，所有的任务都将由aspx, C#这类技术来实现， 采用这种方式开发出来的网站，页面与用户的交互性通常不会很友好，比如：提交数据时经常需要整页刷新。

【门户类网站】，这类网站与之前的【以服务端为中心的网站】有个重要的差别：页面只是呈现数据， 表单的提交全采用AJAX方式了。这样做的好处能将显示逻辑与数据更新逻辑有效的分离，不必纠缠在一起（可认为是二个通道）， 在这种开发模式下，由于页面只负责数据的显示，因此，只要能将业务逻辑尽可能地与UI分离，项目在维护上会容易很多， 采用这种方式开发的网站，页面与用户交互的友好性会好很多，而且也不会影响SEO，因此被较多的门户网站采用。

【纯AJAX网站】，在这类网站中，服务端由于不参与UI处理，网站可以只是些静态的HTML文件， 而且在设计页面时，只要留下一些占位符就可以了，UI元素全部由JS来生成。 这类网站的客户端通常会选择一个JS的UI框架来支持。这类界面相对于前二种来说，会更漂亮，用户的操作体验也会更友好。 但由于页面主要由JS来生成，对SEO的支持较差，因此，特别适合一些后台类的网站项目。