寫程式寫這麼多年了，雖然都是在微軟的平台上奮戰，但使用的技術也不少了，從早期的 VB4, ASP, VB6, Visual C++, .NET Framework 1.x, VB.NET, C#, ADO, ADO.NET, 一直到現在的 ORM, Entity Framework, async/await, ASP.NET MVC, Dependency Injection, AOP, Design Pattern, … 時代一直在進步，技術的演進會持續的上演，這不就是資訊業界 (尤其是軟體開發) 經常會遇到的情況嗎？所以一般來說也見怪不怪...
技術在演進的過程中，總是會改良一些舊平台上的不良作法，以 ASP 和 ASP.NET 來說，最大的改變就是想要讓開發人員將伺服器端程式碼由 HTML 抽離開，讓 HTML 部份盡可能保持乾淨，而程式的操作邏輯與流程全部依賴 Code-behind 的類別來處理，開發人員能將心力集中在程式開發而非前端介面。然而 ASP.NET Web Form 的作法又太過於依賴控制項的描繪方式 (Control-based Rendering)，所以後來才會有 ASP.NET MVC 出線，它的 View 讓開發人員能以類似 ASP 的方式處理介面描繪的工作，以擺脫因為控制項描繪而產生的副作用 – ViewState 和過多的伺服器端介面生成邏輯。
不過，因為專案時程的關係，會有些開發團隊或個人會想要打破這個潛規則，用看起來速度很快的方法來做，基於專案時程的要求基本上沒錯，但是這種打破潛規則的作法很容易用數以倍計的速度累積大量的技術債 (Technical Debt)，這些技術債會讓後續接手的人 (也有可能和開發人員是同一人) 在維護上付出數以百倍計的心力來閱讀與掌握程式碼的邏輯，若這些程式碼是產品的一部份，問題會更加嚴重，但會這樣做的開發人員或團隊，往往很容易以忽略它的角度來看這些問題，因此現階段這樣的情況並沒有太多改善，我們還是會很常在部份 ASP.NET 程式裡看到一大堆的義大利麵程式碼，也能在一堆呼叫資料庫的程式內看到 SQL Injection，原因其實就不用我說了。
技術本來就是因地制宜，ASP.NET Web Form 有其適合的場域，MVC 有其適合的場域，ORM 有其適合的場域，ADO.NET 的寫法也有其適合場域，PM/SA 或開發人員要有基本的概念，讓技術套用到正確的場域，不是說一種技術就套用到所有場域，如果你會這樣想，請盡快改掉，以免日後中了它的餘毒。如果你是因為懶而不去改掉，那就是你的問題。
時程和技術往往都是互斥的，以前 ASP 時代能用 VBScript 透過義大利麵的方式產製 HTML，但到了 ASP.NET 就必須要改用控制項 (即便它仍保留了義大利麵的作法)，對控制項不熟悉的人會選用以前的作法以順利的在時程內交貨，這沒有錯，但是這並不是長久之計，而是要慢慢習慣使用控制項的作法，讓產製的時間能拉回到和使用 VBScript 相同甚至更快，ASP.NET 確實有這樣的能力，所以如果你是 ASP (or PHP/JSP) 要移到 ASP.NET 的話，現在可以選擇 MVC 而不是用 Web Form 入門，以獲得更快與更熟悉的作法來加速或平衡之前的生產力。不過這必須要控制在六個月以內，要求更嚴格的話要控制在三個月內，因為在新的技術上用以前的作法不但得不到新技術的優點，反而會讓缺點大幅的掩蓋了優點，甚至會讓開發人員有 "這樣做就好了，為什麼要用新技術" 的錯誤思維，技術團隊的 PM/Leads/SA 必須要避免團隊成員有這樣的思維出現，技術書籍的作者當然更不應該鼓吹讀者學習如此的錯誤思維。
技術的學習是這一行的常態，想進來這個行業就必須要有覺悟，一招半式走江湖的情況在這行幾乎無法成功 (概率極高，接近 100%)，因此隨時要求自己要能吸收新的技術能量，這是進來這一行的基本原則，而在吸收了新技術後，要能判斷適合的場域應用它，並且在使用它時不要讓舊的思維套用到新的技術上，以避免新技術的優點被舊思維掩蓋成缺點，這是基本的堅持。
當然啦，這是我個人的觀點，你可以不同意，你也可以繼續用舊有的作法，也可以把這篇文視為草芥不值一提，但這是我長久以來在技術這條路上的心得和感想，也是一種對年輕入門者的期許。
Reference: