小朱® 的技術隨手寫

最近發生兩個很有趣的案例，可以發現即便是原廠或作者宣稱很好用的工具，也可能會暗藏危機，尤其是對工具 (也可以套用在某些 Framework 或是元件，程式碼模組上) 的原理或架構不夠了解時，那可能被內含的一些機制或限制暗算的機率會變得很高。

第一個案例，是在 MSDN 論壇上的一個提問：PageMethods 與 XMLHttpRequest。

ASP.NET AJAX 所附屬的許多 AJAX Framework 和控制項如 UpdatePanel, PageMethods 等功能都是可以有效縮短 ASP.NET Programmer 開發 Web 應用程式的好物，但是當你在用 UpdatePanel 時，你知道它在背後做了什麼事嗎？一個看起來很好用的東西，一定是想了一些方法來技術性規避或包裝原有必須要做的事情，才能達到應有的好用功能。但這不代表原有必須要做的事可以不用做，以 UpdatePanel 來說，AJAX Framework 把一個需要片段更新的功能包裝到控制項內，雖然表面上可以做到真的片段更新的功能，但它卻只是把原本頁面更新的機制包裝到 AJAX Framework 內，並沒有將這個步驟省略掉 (只是 AJAX Framework 把這工作吃掉)，因此 ASP.NET 核心用來保存頁面資料的一些狀態資訊，像是 ViewState，都會原封不動的被傳回到 server，再由 ASP.NET 核心進行頁面處理後，才切割這個控制項包裹的使用者介面部份回傳給用戶端，這一大段之間要花多少動作？因此用 UpdatePanel 的 ASP.NET AJAX 應用程式通常效能都會差一點 (時間大多都花在 ASP.NET 核心處理頁面的工作)。

同理，ASP.NET AJAX Framework 提供的 PageMethods 也有相同的問題，PageMethods 可以讓頁面中的方法直接顯露給 Client-side Scripting 取用，有如 Web Service 一般，但為了要讓 PageMethods 發生作用，AJAX Documentation 內說明要開發人員將要作為 Page Method 的方法使用 static 來宣告，我們用公開的秘密：Reflector 來看 System.Web.Extensions.dll 組件 (或者也可以由微軟下載 .NET Framework 的 Reference Source Code 來看)，裡面有一個 System.Web.Script.Services 命名空間，在這個命名空間內有一個 RestHandler 的 HTTP Handler，內含了一個 InvokeMethod() 方法，這個方法會偵測靜態的方法，並呼叫這個方法，再回傳它的回傳值。由此可知，PageMethods 會將 ASP.NET 的靜態頁面包裝成類 Web Service 的方式，直接由 XMLHttpRequest 呼叫 .aspx，而內含的 RestHandler 會處理這個呼叫。當然，為了要讓 ASP.NET 將資料導向到 RestHandler，在用戶端指令中也有一些該做的事。這個部份可以參考 http://www.dotblogs.com.tw/ian/archive/2010/09/09/17627.aspx 的說明。

第二個案例，是在 Facebook 上和 Ruddy 老師討論使用 SharePoint 作為開發平台時，PM 或 SA 的指南的問題，討論串可以在這裡看：http://www.facebook.com/#!/jimycao?v=wall&story_fbid=437487537229&ref=notif&notif_t=feed_comment_reply

SharePoint 最早是由 Content Management Server (CMS) 演化而來，作為企業內部入口網站的建置之用，其實它的問題和 SQL Server 有點像，同一個技術會區分為 for IT PRO 和 for Developer，IT PRO 和 Developer 看同一個技術或產品的角度一定不同，IT PRO 重視的是部署的方式，日後的組態，維運以及故障排除 (以架構師來說，算是 Infrastructure Architect)；而 Developer 重視的是技術提供的開發功能，擴充能力以及開發方法，如同 Windows Azure 提供的 API/Service 與工具等，但 SharePoint 混合了多種微軟技術，以符合在企業環境中建置的需求，之前微軟將 SharePoint Server 用  "SharePoint Technologies" 來稱呼，可不是浪得虛名的。然而，就是因為 SharePoint 的技術混合性很高，因此想要發揮 SharePoint 的能力也很困難，想要駕馭 SharePoint 進行開發的話，要會的東西可能至少有 Active Directory, SQL Server, HTML, Visual Studio, List Collection, Business Data Connector / Business Connectivity Services, Web Parts, …，如此多的東西，想要在短時間內了解其實難度不低。

同樣的問題也發生在許多的 Framework 上，以 jQuery 來舉例，jQuery 也是一個 Framework，它內部也隱含了很多自動處理掉的東西，最典型的就是 selector，在現行瀏覽器處於戰國時代的時期，jQuery 為了要保持一致的 Coding style，它一定要在所有的瀏覽器 (至少在主流的瀏覽器上) 提供相同的作法，才會吸引多數的 Developer 來使用，所以在 jQuery source code 中會看到到處都是 Regular Expression，以將解析器的能力在所有的瀏覽器中都有作用，使用它的開發人員才可以用極簡的 $("div.myClass") 來取出 class="myClass" 的 div 元素，但像 #myID 這種 selector 就要少用，而改用 $(document.getElementById("myID")) 來取代，用瀏覽器原生的方法，會比 jQuery 來的快。其他像是 Spring Framework，MEF (Managed Extensibility Framework) 或是 Code Contract 等，都會有相同的問題。

現在為了要減輕開發人員的負擔，很多的 Application Framework / Functional Framework 在網路上都找的到，很多的工具 (Visual Studio 也是) 也將許多原本應該做的東西精巧的包裝成很簡單的控制項或元件，讓開發人員可以在數分鐘內將功能做出來，生產力是進步了沒錯，但生產力的背後要拿什麼來換？最明顯的就是效能降低或是可維護性變差，可讀性變差或無法找到適合的人來維護 Framework 等等副作用。我不是說使用工具和 Framework 不好，善用這些工具和 Framework 確實可以增加生產力，但如果都盡信工具的話，可能會在無形中挖洞給自己跳，不可不慎。

能善用工具和 Framework 的唯一路徑，就是徹底了解它，以及它背後的基礎知識。這條路雖然不好走，但一定要走過去，否則亂用 Framework 寫出來的程式，不但可能會不倫不類，甚至寫出來的到最後都要整個丟棄 (我就被暗算過，有切身之痛 … )。所以不能把這件事當兒戲啊。