关于技术争论（尤其是ASP.NET Web Forms 和 ASP.NET MVC 之争）

技术争论在博客和twitter里无休止地进行着，这些争论涵盖每个开发人员社区。每个语言，框架，工具，和平台在某个特定的时间都不可避免地会至少有几个争论在进行中。

下面是我多年来对技术争论所做的几个总的观察，以及对一些我最近看到的，尤其是关于ASP.NET Web Forms 和 ASP.NET MVC的最新讨论的一些评论。

关于技术争论的总的观察 下面是几个总的观察，无关任何具体技术争论：

a) 开发人员喜欢充满热情地争论和比较语言，框架，APIs，和工具。每个编程社区（.NET, Java, PHP, C++, Ruby, Python等等）都如此。我认为你可以2种方式来看待这类宗教性的技术争论：

这些争论有时很讨厌，经常是浪费时间。
这些争论经常是一个既健康又活跃的社区的一个标志（因为激情意味着争论双方的人都深切地关注着，远远好过了无兴趣（apathy））。
就个人而言，我认为两者都对。

b) 开发什么东西从没有唯一的“正确之道（one right way）”。作为面试的开场题目，我有时会要求参试者以他们所能的效率最高的方式来对一组数字进行排序，大多数人都做的不是很好。这通常并不是因为他们不知道排序算法，而是因为他们从来不想起来询问其后的场景和需求，而这些对理解效率最高的方式的做法是至关紧要的。数字序列有多大？典型数字序列的随机度有多高？（是否大部分已经排好序了？数字差幅有多大？数字都是独特的么？重复数字是否群集在一起？）计算机架构的平行度有多高？作为排序的一部分，能否分配内存还是内存必须是常量？ 等等。这些都是该问的重要问题，因为一组数字的效率最高和最优的排序方式依赖于对这些答案的理解。

任何时候人们声称某个编程问题只有一个唯一的“正确之道”时，他们几乎总是假定了一套固定的需求/场景/输入，而这对每个场景或每个开发人员来说，很少是最佳的。众所周知，编程中的大多数问题比将一组数字进行排序要复杂多了。

c) 优秀的开发人员使用差的工具/框架也能造出优秀应用来，差的开发人员使用优秀的工具/框架也能造出差的应用来。在根据所用的工具/框架对你正建造的应用的质量来做太广的假定（无论好坏）时要千万谨慎。

d) 开发人员（好的和差的）可以通过延伸自己，学习新的思路和方式方法来变得更加强大。即时他们最终并不直接使用新的东西，学习这个行动本身就能以积极的方式使得他们变得锐利。

e) 在技术行业里，变化是永恒的。变化可以令人害怕。但你是否被变化压倒（get overwhelmed），归根到底取决于你是否让你自己被压倒。别太担心需要停下来，突然学一堆新东西，你很少需要那么做。 避免被压倒的最好方法就是务实，对大范围的东西在高的层次上保持相当地了解（而不仅仅是技术和工具，也包括方法学），有自信认识到，如果学一门新技术很重要，那么你现有的开发技能的绝大部分能够转移过去并且有所帮助。不管怎样，对开发而言，句法和APIs很少是最重要的东西，问题的解决，客户共鸣和互动（customer empathy/engagement），以及能够专注一个项目并且训练有素的能力，更为宝贵。

f) 下面是我偶尔会给我的开发团队的人员一些在与他人协作和交流时的引导：

告诉别人他们很蠢，你很少会赢得争论，无论你对他们智商问题的解释是多么有善意，或者是多么有说服力。
总有某个人，在世界上某个地方，比你更聪明，- 别总是假设他们跟你不在一个屋里。
你交流的人往往会忘记你给予他们的赞誉，往往会记住以前的侮辱，- 所以说话时一定要审慎，否则后患无穷（come back to haunt you later）。
人们可以改变主意，也会改变主意， - 所以在争论中一定不要固执己见,他们改变主意的话,也别洋洋得意或者歧视他们。
g) 当我听人埋怨编程抽象不太好时, 我总是发现有点啼笑皆非，特别是当这些埋怨是通过博客来发表的时候，想想博客内容是使用HTML来显示的，用CSS来做的样式，用JavaScript来做交互的，在线上是用HTTP传输的，在服务器端是用高级语言编写的应用实现的，使用了面向对象的，垃圾回收的框架，是在解释的或JIT编译的字节码运行时之上运行的，博客内容和评论最终是保存在关系数据库中的，最终还是通过SQL查询字符串来访问的。所有的这些都是在主机服务器上的VM中运行的，而VM中的OS以kernel模式和用户模式进程界限对内存进行分配，使用线程调度工作，使用信号触发设备事件，使用抽象的存储API做硬盘持久。等下一次你读到 “ORM与存储过程之比较” 或者 “服务器控件，是好是坏？” 贴子的时候，非常值得把所有这些东西在脑子里再回想一番。而更有趣的争论都是关于特定问题的最佳抽象的。

h) 编程争论的历史是一个漫长的无限循环，其实大多数的编程想法都早已被解决过很多次了。不管是真是假，我们今天争论的许多问题很久以前就已在LISP 和 Smalltalk中解决了。令人啼笑皆非的是，尽管非常优雅地开创了许多东西，这二门语言却用得不太多了，琢磨去吧。

针对ASP.NET Web Forms / ASP.NET MVC之争的一些评论： 下面是对我最近看到在社区里传播的一些争论的几个评论，这些争论是关于ASP.NET Web Forms 和 ASP.NET MVC哪个方案最好的：

a) Web Forms 和 MVC是用来建造ASP.NET应用的2种方案，它们都是不错的选择。取决于应用的需求和参与开发的团队成员的背景，对特定的问题，每个方案都可以成为“最佳选择”。你可以使用两者中的任意一个建造出优秀应用来。你也可以使用两者中的任意一个建造出糟糕应用来。你是好的还是差的开发人员，并不取决于你选择了什么。使用两者，你可以是绝对地棒，也可以是毫无用处。

b) ASP.NET 和 Visual Studio开发团队在Web Forms 和 MVC上都投下了大量资源，随便哪个都不会消失。两者在接下来的几个月内都会有重大发布。ASP.NET 4包含了对Web Forms的重大更新 （干净的 ClientID 和 基于CSS的标识输出，较小的ViewState, URL导向， 新的数据和报表控件， 新的动态数据特性，新的SEO APIs, 新的VS设计器和项目改进等等）。ASP.NET 4中还会同时发布ASP.NET MVC 2，其中包含了重大的更新（强类型的辅助方法，模型验证，多区域，更好的脚手架支持，异步支持，更多的辅助方法APIs等）。别担心其中一个会变成死路一条或者你必须转向某一个。我怀疑，在我们大家都死了很久以后，在Internet某个地方还会有服务器依然还在运行基于 ASP.NET Web Forms 和 ASP.NET MVC两者的应用。

c) Web Forms 和 MVC 间共享的代码/基础设施/APIs 远远超过了参与争论双方的任意一位所提到的，- 认证，授权，成员，角色，URL导向，缓存，会话状态，用户信息，配置，编译，.aspx网页, .master 文件, .ascx 文件, Global.asax, 请求/回复/Cookie APIs, 健康监测，进程模型，跟踪，部署，AJAX, 等等等等。无论你是怎么构建你的UI的，你学到的所有常用的东西还是同样有效的。在未来，我们将继续投入大量资源建造可用于Web Forms 和 MVC两者的核心ASP.NET特性（ 象URL导向，部署，输出缓存，和我们加到 ASP.NET 4 中的DataAnnotation的验证特性）。

d) 我经常发现围绕着编程模型之合适性和抽象的争论有点可笑。Web Forms 和 MVC两者都是编程web框架抽象，是建立在更广的框架抽象之上的，以高级编程语言编程，在运行引擎抽象之上运行，而运行引擎抽象本身又是在名为OS的巨大抽象之上运行的。你用Web Forms 和 MVC创建的是 HTML/CSS/JavaScript （所有的抽象都被持久为文本，在HTTP之上传输，而HTTP则是另一个高层次的协议抽象）。

该争论的有趣的问题不是这些抽象是好还是坏，而应该是哪个抽象你感觉最自然，哪个抽象与你项目的需要/场景/开发人员最匹配。

e) 我们即将对www.asp.net网站做一个非常重大的更新。作为更新的一部分，我们将发表更多的全程（end to end）教程/内容（Web Forms和MVC两者都有）。我们还将提供教程和指引，帮助开发人员很快地评估Web Forms和MVC两种方案，轻松地学习两者的工作原理基础，很快地决定哪个他们感觉最好。这将方便新的ASP.NET开发人员，以及已经知晓Web Forms或者MVC的开发人员，来理解和评估这2种方案，然后决定他们想要使用哪个方案。

f) 决定某个项目你究竟想使用Web Forms还是MVC，然后对此决定你要感觉高兴。两者都是好的选择。尊重别人做的选择，他们做的选择希望是一个好的，并且进展会顺利的选择。记住，十有八九，他们对他们自己的业务/技能的了解要比你所了解的多得多。同样地，希望你对你自己的业务/技能的了解也比他们所了解的多得多。

g) 与他人共享想法和最佳实践， 那是博客，论坛，邮件列单和社区的一个重大部分。它们之所以成功，是当人们知道他们的想法不会被批得体无完肤，而且他们会受到尊重的对待。请有建设性，而不是刻薄。请教授，而不是教训。记住，三人行，必有我师。

希望本文对你有所帮助，

Scott

 

英文原文

[In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu]

Technical debates are discussed endlessly within the blog-o-sphere/twitter-verse, and they range across every developer community. Each language, framework, tool, and platform inevitably has at least a few going on at any particular point in time.

Below are a few observations I’ve made over the years about technical debates in general, as well as some comments about some of the recent discussions I’ve seen recently about the topic of ASP.NET Web Forms and ASP.NET MVC in particular.

General Observations About Technical Debates Below are a few general observations independent of any specific technical debate:

a) Developers love to passionately debate and compare languages, frameworks, APIs, and tools.  This is true in every programming community (.NET, Java, PHP, C++, Ruby, Python, etc).  I think you can view these types of religious technical debates in two ways:

They are sometimes annoying and often a waste of time.
They are often a sign of a healthy and active community (since passion means people care deeply on both sides of a debate, and is far better than apathy).
Personally I think both points are true.

b) There is never only “one right way” to develop something. As an opening interview question I sometimes ask people to sort an array of numbers in the most efficient way they can.  Most people don’t do well with it.  This is usually not because they don’t know sort algorithms, but rather because they never think to ask the scenarios and requirements behind it – which is critical to understanding the most efficient way to do it.  How big is the sequence of numbers? How random is the typical number sequence (is it sometimes already mostly sorted, how big is the spread of numbers, are the numbers all unique, do duplicates cluster together)? How parallel is the computer architecture?  Can you allocate memory as part of the sort or must it be constant?  Etc. These are important questions to ask because the most efficient and optimal way to sort an array of numbers depends on understanding the answers.

Whenever people assert that there is only “one right way” to a programming problem they are almost always assuming a fixed set of requirements/scenarios/inputs – which is rarely optimal for every scenario or every developer.  And to state the obvious - most problems in programming are far more complex than sorting an array of numbers.

c) Great developers using bad tools/frameworks can make great apps. Bad developers using great tools/frameworks can make bad apps. Be very careful about making broad assumptions (good or bad) about the quality of the app you are building based on the tools/frameworks used.

d) Developers (good and bad) can grow stronger by stretching themselves and learning new ideas and approaches.  Even if they ultimately don’t use something new directly, the act of learning it can sharpen them in positive ways.

e) Change is constant in the technology industry.  Change can be scary.  Whether you get overwhelmed by change, though, ultimately comes down to whether you let yourself be overwhelmed.  Don’t stress about having to stop and suddenly learn a bunch of new things - rarely do you have to. The best approach to avoid being overwhelmed is to be pragmatic, stay reasonably informed about a broad set of things at a high-level (not just technologies and tools but also methodologies), and have the confidence to know that if it is important to learn a new technology, then your existing development skills will mostly transition and help.  Syntax and APIs are rarely the most important thing anyway when it comes to development – problem solving, customer empathy/engagement, and the ability to stay focused and disciplined on a project are much more valuable.

f) Some guidance I occasionally give people on my team when working and communicating with others:

You will rarely win a debate with someone by telling them that they are stupid - no matter how well intentioned or eloquent your explanation of their IQ problems might be.
There will always be someone somewhere in the world who is smarter than you - don’t always assume that they aren’t in the room with you.
People you interact with too often forget the praise you give them, and too often remember a past insult -  so be judicious in handing them out as they come back to haunt you later. 
People can and do change their minds - be open to being persuaded in a debate, and neither gloat nor hold it against someone else if they also change their minds.
g) I always find it somewhat ironic when I hear people complain about programming abstractions not being good.  Especially when these complaints are published via blogs – whose content is displayed using HTML, is styled with CSS, made interactive with JavaScript, transported over the wire using HTTP, and implemented on the server with apps written in higher-level languages, using object oriented garbage collected frameworks, running on top of either interpreted or JIT-compiled byte code runtimes, and which ultimately store the blog content and comments in relational databases ultimately accessed via SQL query strings.  All of this running within a VM on a hosted server – with the OS within the VM partitioning memory across kernel and user mode process boundaries, scheduling work using threads, raising device events using signals, and using an abstract storage API fo disk persistence.  It is worth keeping all of that in mind the next time you are reading a “ORM vs Stored Procedures” or “server controls – good/bad?” post.  The more interesting debates are about what the best abstractions are for a particular problem.

h) The history of programming debates is one long infinite loop – with most programming ideas having been solved multiple times before.  And for what it’s worth – many of the problems we debate today were long ago solved with LISP and Smalltalk.  Ironically, despite pioneering a number of things quite elegantly, these two languages tend not be used much anymore. Go figure.

Some Comments Specific to ASP.NET Web Forms / ASP.NET MVC debates: Below are a few comments specific to some of the recent debates that I’ve seen going around within the community as to whether a ASP.NET Web Forms or ASP.NET MVC based approach is best:

a) Web Forms and MVC are two approaches for building ASP.NET apps. They are both good choices. Each can be the “best choice” for a particular solution depending on the requirements of the application and the background of the team members involved. You can build great apps with either.  You can build bad apps with either. You are not a good or bad developer depending on what you choose. You can be absolutely great or worthless using both.

b) The ASP.NET and Visual Studio teams are investing heavily in both Web Forms and MVC.  Neither is going away.  Both have major releases coming in the months ahead.  ASP.NET 4 includes major updates to Web Forms (clean ClientIDs and CSS based markup output, smaller ViewState, URL Routing, new data and charting controls, new dynamic data features, new SEO APIs, new VS designer and project improvements, etc, etc).  ASP.NET 4 will also ship with ASP.NET MVC 2 which also includes major updates (strongly typed helpers, model validation, areas, better scaffolding, Async support, more helper APIs, etc, etc).  Don’t angst about either being a dead-end or something you have to change to.  I suspect that long after we are all dead and gone there will be servers somewhere on the Internet still running both ASP.NET Web Forms and ASP.NET MVC based apps.

c) Web Forms and MVC share far more code/infrastructure/APIs than anyone on either side of any debate about them ever mentions - Authentication, Authorization, Membership, Roles, URL Routing, Caching, Session State, Profiles, Configuration, Compilation, .aspx pages, .master files, .ascx files, Global.asax, Request/Response/Cookie APIs, Health Monitoring, Process Model, Tracing, Deployment, AJAX, etc, etc, etc.  All of that common stuff you learn is equally valid regardless of how you construct your UI.  Going forward we’ll continue to invest heavily in building core ASP.NET features that work for both Web Forms and MVC (like the URL Routing, Deployment, Output Caching, and DataAnnotations for Validation features we are adding with ASP.NET 4).

d) I often find debates around programming model appropriateness and abstractions a little silly. Both Web Forms and MVC are programming web framework abstractions, built on top of a broader framework abstraction, programmed with higher level programming languages, running on top of a execution engine abstraction that itself is running on top of a giant abstraction called an OS.  What you are creating with each is HTML/CSS/JavaScript (all abstractions persisted as text, transmitted over HTTP – another higher level protocol abstraction).

The interesting question to debate is not whether abstractions are good or not – but rather which abstractions feels most natural to you, and which map best to the requirements/scenarios/developers of your project.

e) We are about to do a pretty major update to the www.asp.net site.  As part of that we will be posting more end to end tutorials/content (for both Web Forms and MVC).  We will also be providing tutorials and guidance that will help developers quickly evaluate both the Web Forms and MVC approach, easily learn the basics about how both work, and quickly determine which one feels best for them to use. This will make it easy for developers new to ASP.NET, as well as developers who already know either Web Forms or MVC, to understand and evaluate the two approaches and decide which they want to use.

f) Decide on a project about whether you want to use Web Forms or MVC and feel good about it.  Both can be good choices.  Respect the choices other people make – the choice they have made is also hopefully a good one that works well for them.  Keep in mind that in all likelihood they know a lot more about their own business/skills than you do.  Likewise you hopefully know a lot more about your own business/skills than they do.

g) Share ideas and best practices with others.  That is a big part of what blogs, forums, listservs and community is all about.  What makes them work great is when people know that their ideas aren’t going to be ripped to shreds, and that they will be treated with respect.  Be constructive, not snarky. Teach, don’t lecture. Remember there is always someone else out there who you can also learn from.

Hope this helps,

Scott