http://www.garrettdimon.com/archives/aspnet-vs-front-end-architecture
该文作者细数了他在使用ASP.NET进行开发的过程中遇到的6点不爽的地方，主要都集中在前台架构上，包括大量内联的风格标签、不同浏览器生成不同页面代码、失败的标记设计、缺乏语意一致性、服务器端label和客户端label的脱节、服务器端ID和客户端ID脱节等等。尤其当你想使用标准的CSS，构建数据结构和表现分离的清晰页面时，ASP.NET的一些默认的内部处理可以让你对ASP.NET为何这样做完全无语。比较有趣的是本文后面的回复，其中有不少与楼主同病相怜的网友，还有来自微软员工的为ASP.NET辩护的声音。
我一直对MS在很多设计思路和决定上心存疑虑，不明白为什么MS硬是要自成风格搞自己那一套蹩脚的所谓"规范"或"标准"，似乎在鼓励大家follow一个并不清晰、多少有些混杂无章的设计架构，其实为了方便它实现更cool的WYSIWYG开发工具。就拿今天来说，本来我们项目定义好所有模块都按BO和UI分开，BO里面的类和UI里面的类各施其责，原则上UI依赖BO，而不是反过来，按照我的理解和期望，Windows.Forms命名空间应该是由UI层来依赖，而非BO层。很显然，因为我们的form都放在UI层，肯定是依赖Windows.Forms了，而我们尽可能把所有业务逻辑代码放到BO层。但是为了临时实现一个文本文件形式的log，因为我们的业务逻辑代码都在BO层，所以为了记录有意义的log，我们的log逻辑自然而然只能放在BO层。但是一个基本的获取程序运行路径的方法属于System.Windows.Forms.Application类，让我们不得不using System.Windows.Froms。这其实还好，我们也许不应该强求Windows.Forms一定就是只针对UI上的应用。问题是你每天都在面对类似的情况，每天都或多或少在和.NET API和框架其他部分在打架，当你使用.NET的API时间久了，自然而然你就被它带到它的那一套思路中，你的设计也就自然而然跟着它走了，业务逻辑和UI逻辑交织在一起，当你回过头来想把层次理清理顺已经成为Mission:Impossible。因为抛开MS推荐的方式，自己实现一套自认更清晰的架构，相较"官方"的blueprint设计，代价实在有些高。
所以虽然我没有真正开发过ASP.NET，尤其是2.0版，但我很能理解他们遇到的尴尬。