技術(shù)爭論在博客和twitter里無休止地進行著，這些爭論涵蓋每個開發(fā)人員社區(qū)。每個語言，框架，工具，和平臺在某個特定的時間都不可避免地會至少有幾個爭論在進行中。

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

　　關(guān)于技術(shù)爭論的總的觀察

　　下面是幾個總的觀察，無關(guān)任何具體技術(shù)爭論：

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

　　1. 這些爭論有時很討厭，經(jīng)常是浪費時間。
　　2. 這些爭論經(jīng)常是一個既健康又活躍的社區(qū)的一個標(biāo)志（因為激情意味著爭論雙方的人都深切地關(guān)注著，遠(yuǎn)遠(yuǎn)好過了無興趣（apathy））。

　　就個人而言，我認(rèn)為兩者都對。

　　（二） 開發(fā)什么東西從沒有唯一的“正確之道（one right way）”。作為面試的開場題目，我有時會要求參試者以他們所能的效率最高的方式來對一組數(shù)字進行排序，大多數(shù)人都做的不是很好。這通常并不是因為他們不知道排序算法，而是因為他們從來不想起來詢問其后的場景和需求，而這些對理解效率最高的方式的做法是至關(guān)緊要的。數(shù)字序列有多大？典型數(shù)字序列的隨機度有多高？（是否大部分已經(jīng)排好序了？數(shù)字差幅有多大？數(shù)字都是獨特的么？重復(fù)數(shù)字是否群集在一起？）計算機架構(gòu)的平行度有多高？作為排序的一部分，能否分配內(nèi)存還是內(nèi)存必須是常量？ 等等。這些都是該問的重要問題，因為一組數(shù)字的效率最高和最優(yōu)的排序方式依賴于對這些答案的理解。

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

　　（三） 優(yōu)秀的開發(fā)人員使用差的工具/框架也能造出優(yōu)秀應(yīng)用來，差的開發(fā)人員使用優(yōu)秀的工具/框架也能造出差的應(yīng)用來。在根據(jù)所用的工具/框架對你正建造的應(yīng)用的質(zhì)量來做太廣的假定（無論好壞）時要千萬謹(jǐn)慎。

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

　　（五） 在技術(shù)行業(yè)里，變化是永恒的。變化可以令人害怕。但你是否被變化壓倒（get overwhelmed），歸根到底取決于你是否讓你自己被壓倒。別太擔(dān)心需要停下來，突然學(xué)一堆新東西，你很少需要那么做。 避免被壓倒的最好方法就是務(wù)實，對大范圍的東西在高的層次上保持相當(dāng)?shù)亓私猓ǘ粌H僅是技術(shù)和工具，也包括方法學(xué)），有自信認(rèn)識到，如果學(xué)一門新技術(shù)很重要，那么你現(xiàn)有的開發(fā)技能的絕大部分能夠轉(zhuǎn)移過去并且有所幫助。不管怎樣，對開發(fā)而言，句法和APIs很少是最重要的東西，問題的解決，客戶共鳴和互動（customer empathy/engagement），以及能夠?qū)Ｗ⒁粋€項目并且訓(xùn)練有素的能力，更為寶貴。

　　（六） 下面是我偶爾會給我的開發(fā)團隊的人員一些在與他人協(xié)作和交流時的引導(dǎo)：

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

　　（七） 當(dāng)我聽人埋怨編程抽象不太好時, 我總是發(fā)現(xiàn)有點啼笑皆非，特別是當(dāng)這些埋怨是通過博客來發(fā)表的時候，想想博客內(nèi)容是使用HTML來顯示的，用CSS來做的樣式，用JavaScript來做交互的，在線上是用HTTP傳輸?shù)模?a href=/yuedu/fuwuqi/ target=_blank class=infotextkey>服務(wù)器端是用高級語言編寫的應(yīng)用實現(xiàn)的，使用了面向?qū)ο蟮模厥盏目蚣埽窃诮忉尩幕騄IT編譯的字節(jié)碼運行時之上運行的，博客內(nèi)容和評論最終是保存在關(guān)系數(shù)據(jù)庫中的，最終還是通過SQL查詢字符串來訪問的。所有的這些都是在主機服務(wù)器上的VM中運行的，而VM 中的OS以kernel模式和用戶模式進程界限對內(nèi)存進行分配，使用線程調(diào)度工作，使用信號觸發(fā)設(shè)備事件，使用抽象的存儲API做硬盤持久。等下一次你讀到 “ORM與存儲過程之比較” 或者 “服務(wù)器控件，是好是壞？” 貼子的時候，非常值得把所有這些東西在腦子里再回想一番。而更有趣的爭論都是關(guān)于特定問題的最佳抽象的。

　　（八） 編程爭論的歷史是一個漫長的無限循環(huán)，其實大多數(shù)的編程想法都早已被解決過很多次了。不管是真是假，我們今天爭論的許多問題很久以前就已在LISP 和 Smalltalk中解決了。令人啼笑皆非的是，盡管非常優(yōu)雅地開創(chuàng)了許多東西，這二門語言卻用得不太多了，琢磨去吧。

　　針對 ASP.NET Web Forms / ASP.NET MVC之爭的一些評論：

　　下面是對我最近看到在社區(qū)里傳播的一些爭論的幾個評論，這些爭論是關(guān)于ASP.NET Web Forms 和 ASP.NET MVC哪個方案最好的：

　　（一） Web Forms 和 MVC是用來建造ASP.NET應(yīng)用的2種方案，它們都是不錯的選擇。取決于應(yīng)用的需求和參與開發(fā)的團隊成員的背景，對特定的問題，每個方案都可以成為 “最佳選擇”。你可以使用兩者中的任意一個建造出優(yōu)秀應(yīng)用來。你也可以使用兩者中的任意一個建造出糟糕應(yīng)用來。你是好的還是差的開發(fā)人員，并不取決于你選擇了什么。使用兩者，你可以是絕對地棒，也可以是毫無用處。

　　（二） ASP.NET 和 Visual Studio開發(fā)團隊在Web Forms 和 MVC上都投下了大量資源，隨便哪個都不會消失。兩者在接下來的幾個月內(nèi)都會有重大發(fā)布。ASP.NET 4包含了對Web Forms的重大更新 （干凈的 ClientID 和 基于CSS的標(biāo)識輸出，較小的ViewState, URL導(dǎo)向， 新的數(shù)據(jù)和報表控件， 新的動態(tài)數(shù)據(jù)特性，新的SEO APIs, 新的VS設(shè)計器和項目改進等等）。ASP.NET 4中還會同時發(fā)布ASP.NET MVC 2，其中包含了重大的更新（強類型的輔助方法，模型驗證，多區(qū)域，更好的腳手架支持，異步支持，更多的輔助方法APIs等）。別擔(dān)心其中一個會變成死路一條或者你必須轉(zhuǎn)向某一個。我懷疑，在我們大家都死了很久以后，在InterNET某個地方還會有服務(wù)器依然還在運行基于 ASP.NET Web Forms 和 ASP.NET MVC兩者的應(yīng)用。

　　（三） Web Forms 和 MVC 間共享的代碼/基礎(chǔ)設(shè)施/APIs 遠(yuǎn)遠(yuǎn)超過了參與爭論雙方的任意一位所提到的，- 認(rèn)證，授權(quán)，成員，角色，URL導(dǎo)向，緩存，會話狀態(tài)，用戶信息，配置，編譯，.ASPx網(wǎng)頁, .master 文件, .ascx 文件, Global.asax, 請求/回復(fù)/Cookie APIs, 健康監(jiān)測，進程模型，跟蹤，部署，AJAX, 等等等等。無論你是怎么構(gòu)建你的UI的，你學(xué)到的所有常用的東西還是同樣有效的。在未來，我們將繼續(xù)投入大量資源建造可用于Web Forms 和 MVC兩者的核心ASP.NET特性（ 象URL導(dǎo)向，部署，輸出緩存，和我們加到 ASP.NET 4 中的DataAnnotation的驗證特性）。

　　（四） 我經(jīng)常發(fā)現(xiàn)圍繞著編程模型之合適性和抽象的爭論有點可笑。Web Forms 和 MVC兩者都是編程web框架抽象，是建立在更廣的框架抽象之上的，以高級編程語言編程，在運行引擎抽象之上運行，而運行引擎抽象本身又是在名為OS的巨大抽象之上運行的。你用Web Forms 和 MVC創(chuàng)建的是 HTML/CSS/JavaScript （所有的抽象都被持久為文本，在HTTP之上傳輸，而HTTP則是另一個高層次的協(xié)議抽象）。

　　該爭論的有趣的問題不是這些抽象是好還是壞，而應(yīng)該是哪個抽象你感覺最自然，哪個抽象與你項目的需要/場景/開發(fā)人員最匹配。

　　（五） 我們即將對www.ASP.NET網(wǎng)站做一個非常重大的更新。作為更新的一部分，我們將發(fā)表更多的全程（end to end）教程/內(nèi)容（Web Forms和MVC兩者都有）。我們還將提供教程和指引，幫助開發(fā)人員很快地評估Web Forms和MVC兩種方案，輕松地學(xué)習(xí)兩者的工作原理基礎(chǔ)，很快地決定哪個他們感覺最好。這將方便新的ASP.NET開發(fā)人員，以及已經(jīng)知曉Web Forms或者MVC的開發(fā)人員，來理解和評估這2種方案，然后決定他們想要使用哪個方案。

　　（六） 決定某個項目你究竟想使用Web Forms還是MVC，然后對此決定你要感覺高興。兩者都是好的選擇。尊重別人做的選擇，他們做的選擇希望是一個好的，并且進展會順利的選擇。記住，十有八九，他們對他們自己的業(yè)務(wù)/技能的了解要比你所了解的多得多。同樣地，希望你對你自己的業(yè)務(wù)/技能的了解也比他們所了解的多得多。

　　（七） 與他人共享想法和最佳實踐， 那是博客，論壇，郵件列單和社區(qū)的一個重大部分。它們之所以成功，是當(dāng)人們知道他們的想法不會被批得體無完膚，而且他們會受到尊重的對待。請有建設(shè)性，而不是刻薄。請教授，而不是教訓(xùn)。記住，三人行，必有我?guī)煛?/p>

　　希望本文對你有所幫助，

　　Scott

NET技術(shù)：關(guān)于技術(shù)爭論（尤其是ASP.NETWebForms 和 ASP.NETMVC 之爭），轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。