本文是編譯稿件，原文出處：http://www.asptoday.com/articles/20000121.htm
你剛剛把最新的龐大的ASP應用程式釋放到網上。檔案正確地上傳到伺服器上，與應用程式的連結也
工作良好。在慶祝勝利之前，你想在應用程式的效能上運行一些stats 以便發現它到底有多好。結果
卻發現，本來在開發環境下工作得很好的應用程式實際上運行速度很慢。
對於那些使用Microsoft 軟體包時間不長的人，DNA代表分布式InterNet 結構，是另一種非常熱門的
n層應用程式結構的首字母縮寫形式。Microsoft 致力於在Internet上展開的分布式應用程式的開發。
基於這種思路，未來將流行小型的、無狀態的、組件化的應用程式就不足為奇了。
上面是ASP用於n層環境的典型圖示。web類（IIS應用程式）不是必需的，因為ASP可以直接與表述層
或商業規則層組件對話。因為大多數應用程式都是用ASP單獨寫成的，所以一個情理中的問題就是：
為什麼要將代碼轉入COM組件？
以我之見，ASP只是用於表述層代碼的，所以我選擇將商業規則邏輯或任何形式的資料存取
都裝入COM組件中。一般情況下，我從一開始就將應用程式的代碼分成各個組件，但是通常你並不能選
擇所要處理的結構，所以代碼移植就是個實際問題。在一個n層應用程式中，你必須儘力把非表述代碼
從ASP中儘快移走。
也許目前你並沒有在進行n層編程，那麼移植代碼的適當時機就是運行效能開始削弱時。通常，這是指
你的老闆說“程式今天運行有點慢”到“你被解僱了”之間這段時間。一旦使用者開始抱怨就晚了。
第二個使用移植代碼的方針是當你有足夠的相似代碼（例如所有的資料存取）可以放在一個包含檔案
(.inc) 中以保證一個COM組件時。多少個程式就足夠？這個問題提得好！編寫小型的MTS 組件時，我
發現有一個程式就足夠建立一個COM組件了。但是只有一個程式的COM組件是很罕見的，所以對於這個
問題就需要進行判斷。如果你寫的代碼足夠長，就開始進行模式開發了。當你遭遇到ASP的“陰暗面”
之後（aka COM組件）你就會感覺到其力量。
