關於技術爭論（尤其是ASP.NET Web Forms 和 ASP.NET MVC 之爭）

技術爭論在部落格和twitter裡無休止地進行著，這些爭論涵蓋每個開發人員社區。每個語言，架構，工具，和平台在某個特定的時間都不可避免地會至少有幾個爭論在進行中。

下面是我多年來對技術爭論所做的幾個總的觀察，以及對一些我最近看到的，尤其是關於ASP.NET Web Forms 和 ASP.NET MVC的最新討論的一些評論。

關於技術爭論的總的觀察

下面是幾個總的觀察，無關任何具體技術爭論：

a) 開發人員喜歡充滿熱情地爭論和比較語言，架構，APIs，和工具。每個編程社區（.NET, Java, PHP, C++, Ruby, Python等等）都如此。我認為你可以2種方式來看待這類宗教性的技術爭論：

1. 這些爭論有時很討厭，經常是浪費時間。
2. 這些爭論經常是一個既健康又活躍的社區的一個標誌（因為激情意味著爭論雙方的人都深切地關注著，遠遠好過了沒有興趣（apathy））。

就個人而言，我認為兩者都對。

b) 開發什麼東西從沒有唯一的“正確之道（one right way）”。作為面試的開場題目，我有時會要求參試者以他們所能的效率最高的方式來對一組數字進行排序，大多數人都做的不是很好。這通常並不是因為他們不知道排序演算法，而是因為他們從來不想起來詢問其後的情境和需求，而這些對理解效率最高的方式的做法是至關緊要的。數字序列有多大？典型數字序列的隨機度有多高？（是否大部分已經排好序了？數字差幅有多大？數字都是獨特的嗎？重複數字是否群集在一起？）電腦架構的平行度有多高？作為排序的一部分，能否分配記憶體還是記憶體必須是常量？ 等等。這些都是該問的重要問題，因為一組數位效率最高和最優的排序方式依賴於對這些答案的理解。

任何時候人們聲稱某個編程問題只有一個唯一的“正確之道”時，他們幾乎總是假定了一套固定的需求/情境/輸入，而這對每個情境或每個開發人員來說，很少是最佳的。眾所周知，編程中的大多數問題比將一組數字進行排序要複雜多了。

c) 優秀的開發人員使用差的工具/架構也能造出優秀應用來，差的開發人員使用優秀的工具/架構也能造出差的應用來。在根據所用的工具/架構對你正建造的應用的品質來做太廣的假定（無論好壞）時要千萬謹慎。

d) 開發人員（好的和差的）可以通過延伸自己，學習新的思路和方式方法來變得更加強大。即時他們最終並不直接使用新的東西，學習這個行動本身就能以積極的方式使得他們變得銳利。

e) 在技術行業裡，變化是永恒的。變化可以令人害怕。但你是否被變化壓倒（get overwhelmed），歸根到底取決於你是否讓你自己被壓倒。別太擔心需要停下來，突然學一堆新東西，你很少需要那麼做。 避免被壓倒的最好方法就是務實，對大範圍的東西在高的層次上保持相當地瞭解（而不僅僅是技術和工具，也包括方法學），有自信認識到，如果學一門新技術很重要，那麼你現有的開發技能的絕大部分能夠轉移過去並且有所協助。不管怎樣，對開發而言，句法和APIs很少是最重要的東西，問題的解決，客戶共鳴和互動（customer empathy/engagement），以及能夠專註一個項目並且訓練有素的能力，更為寶貴。

f) 下面是我偶爾會給我的Team Dev的人員一些在與他人協作和交流時的引導：

1. 告訴別人他們很蠢，你很少會贏得爭論，無論你對他們智商問題的解釋是多麼有善意，或者是多麼有說服力。
2. 總有某個人，在世界上某個地方，比你更聰明，- 別總是假設他們跟你不在一個屋裡。
3. 你交流的人往往會忘記你給予他們的讚譽，往往會記住以前的侮辱，- 所以說話時一定要審慎，否則後患無窮（come back to haunt you later）。
4. 人們可以改變主意，也會改變主意， - 所以在爭論中一定不要固執己見,他們改變主意的話,也別洋洋得意或者歧視他們。

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 StudioTeam Dev在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:

1. They are sometimes annoying and often a waste of time.
2. 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:

1. 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.
2. 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.
3. 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. 
4. 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