小朱® 的技術隨手寫

[VS2010] ASP.NET 4.0 新功能：ASP.NET MVC 2.0 Strong-typed HTML Helpers

MSDeploy 是 Visual Studio 2010 提出的 Web 應用程式部署功能，改變了以往的 Web 應用程式部署的方式，不但簡化很多的工作，也可以有效率進行多類型與多組態的部署作業。

[VS2010] 好用的 SQL Azure 資料庫開發的輔助工具 : SQL Azure Explorer

[VS2010] ASP.NET 4.0 新功能：Web.config Minification 與 Transformation

不要讓所謂的 [不用寫任何一行程式] 把自己的發展性侷限了

摘要:[活動] MSDN and TechNet 聯合版聚台中場報導

記錄(logging)這件事在中大型應用系統中，是非常重要的一環，它可以重現資料變動的前後狀況，以及是誰去動了資料，如何動資料等等，除了作為財務部門稽核的基本資料外，也是一種保護自己的證據。

老實說，我從沒有特別去想過等級這件事，因為網頁程式要會的東西就是那些，沒什麼好說嘴的，不過最近在 PTT 上看到一篇有關於這個的討論，就把它轉貼過來了，大家也可以發表一下自己的看法。

經過Part 1 和 Part 2 的試練以後，我想你應該已經有一個自己的 Configuration 系統了，而且也用的很開心，終於可以擺脫掉一大堆 appSettings 的噩夢了，而且只要修改 Web.config 的區段就可以變更程式的設定值。但用久了總是會不太對勁，因為目前為止，這些區段都只能獨立存在，而且只有一個。這時可能就會回想以前 appSettings 的好，因為它可以利用 來動態增加項目，不過，這個在你自己的 Configuration 中，其實也是可以做到的。

繼前一篇文章："不要再賴在 appSettings 的屋簷下了，寫個自己的 Configuration 區段吧~" 之後，也許你已經著手，或已經將自己的設定值移到了自己的 section 中，但現在又有一個問題，就是：如果是不用模組的 section，全擠在同一個 section 中很難看，也不容易找。那麼，本文將可以幫助你。

適才點部落正在舉行 ASP.NET 的修練大會，雖然我這篇文章與 ASP.NET 修練大會本身沒啥關係，但我認為卻是很多想做分層應用程式(Multi-tier Application)或是迷惘在為什麼應用程式總是要重寫很多次的開發人員應該要知道的概念。

jQuery 功能延展（含自訂函式與Plug-in）初體驗

修改jQuery的Plug-in插件以相容於Silverlight 2.0。

我想大家都不反對，在剛開始學習寫程式的時候，最依賴的兩樣的東西，就是書 (book) 和範例程式 (sample code)，範例程式在學習程式的道路上一定是不可或缺的重要工具，它帶給你觀念與方法，讓你可以用相同的模式來做到相同的功能，但範例程式碼最終的目的，只是教你特定的需求要怎麼達成而已，若不將它融會貫通的話，很容易就傷到自己。

如果可以由資料庫本身去做彈性設計的話，對於物件使用 ORM 以及擴充上會有正面幫助，物件可以不受物件既有資料表欄位的限制，即可由物件自己去決定會多或會少哪些資料，而資料庫依照物件的要求做出反應，即可確保物件的高彈性，又可以簡化資料表的設計。這個方法即為 Profile 架構。

適當的設計，應該是考量各種可能情況，對程式做的具彈性且可重覆使用的軟體設計，除了基本的物件導向規範以外，還要加入一個守門員的角色：規則（Rule）以及驗證器（Validator）。

筆記：如何使用 Reflection 呼叫參數中帶有 params 類型不定個數參數的方法。

只要程式開發久了，又有面對過不同層次的專案（例如產業不同，性質不同，應用方向不同或是不同的領域知識等），通常都會接觸或是使用很多的技術，而且技術的學習力又和自己本身的基礎能力有相當大的關係，它會左右你學習新技術的快慢，不過今天要談的倒不是學習力，而是決策力（Decision Making）。

這個資訊是 .NET Framework CLR 中的呼叫堆疊（Call Stack）中的資訊，可用來追蹤程式呼叫的順序以及由誰呼叫了什麼函式，通常都會使用 Exception.StackTrace 來抓出程式的哪裡擲出例外，但其實它還有個妙用，就是取得目前程式執行所在的方法資料，以及其歷程記錄。而且重要的是，它可以同時適用於 Debug 與 Release 模式。

前幾天我在幫我顧問公司的員工上課，剛好講題就是 Software Architecture，我在課堂上順便問了一個小問題：Framework 和 Architecture 有什麼不同？結果學員多數都答不出來，因為那間公司都把 Framework 叫做架構，但光是架構這個詞在很多技術用語上都會被套到，那麼，Framework 和 Architecture 到底哪裡不同？

最近有很多朋友在抱怨，有一部份人到論壇問完問題以後，人就不見了，也沒有再回來看問題解了沒，沒有結案也不給回答的人點數什麼的...我都說，你遇到了網路阿飄了。

不論你是在論壇，在部落格，還是在留言板，MSN 或 Plurk 這種即時性通訊的網路服務，與他人的互動已是不可避免且稀鬆平常的事，然而網路雖然是一個虛擬環境，你不一定認識或見過另一端，坐在電腦前的那個真實個體，不過這並不代表你可以為所欲為，不把另一端的人當人看，也不代表你可以在網路上做任何事情，在網路上的互動應和真實互動是一樣的。

一般在寫程式的時候，往往都是要先探詢寫這支程式的需求是什麼，如果有些工作是由流程 (process) 構成的，或者是這件工作可能會橫跨不同的模組（或資料庫），又或者是這個程式預期未來可能會有什麼樣的衍生功能時，就可以試著把這些程式中共同的部份加以抽出，獨立構成一個公用程式庫 (utility) 或是基礎類別 (base class)，而將這些部份抽出的流程即稱為抽象化 (abstraction)。

最近好像很多人都在問這個問題，MSDN Library 資料量是數百本書的規模，而且MSDN Library有如微軟技術的經典，成經典者，均難讀通，要從MSDN Library數百萬字中找出自己想要的東西，其實是需要一點技巧的。

介面導向設計(interface-oriented design) 在軟體架構設計中，是一個必修的技能，不過在整個軟體架構領域中，它只是個入門磚而已，沒有它，想要做好軟體架構是很困難的，原因只有一個：它是基礎。

我想，很多寫 ASP.NET 應用程式的人，都會習慣性的把自己的一些設定值放到 Web.config 中的 appSettings 區域中，然後用 ConfigurationSettings.AppSettings (1.1) 或 ConfigurationManager.AppSettings (2.0+) 來取設定值吧，雖然它是很好用沒錯，但是如果設定一多的話，appSettings 區塊會充斥一大堆的設定值，屆時要分也不太好分（一堆不同模組的設定都混在同一區了），因此，若想要寫中大型 ASP.NET 應用程式的人，可能不得不學一下如何設計自己的 Configuration 區段了。

在類別中使用中介資料宣告，讓開發人員在使用你的類別時可簡單的以宣告方式即可設定元件資訊，而不需要寫程式。

Silverlight 2.0 可以發展多語系的應用程式，只要透過資源檔即可做到 Localization 的能力，但是...它卻有一個討厭的缺陷，想知道是何種缺陷，就點進來看吧。

這...真的是很多做設計的人的悲哀吧。
這個短片是我朋友傳給我看的，心有戚戚焉啊，所以分享給大家看看。

「a... 怎麼看起來好像又回到了 ASP 時代？」
「a... 這個好複雜哦，看不懂捏...」
我想，這是初次看 ASP.NET MVC Framework 的第一印象吧，因為我第一次看到時也有這樣的疑問。