業務邏輯在一個系統中可放的地方很多，有的人選擇放在存儲過程中，有的人會選擇放在業務組件中，這些方式都可以進行業務邏輯的判斷。既然提供了這些方式都可以實現業務邏輯的判斷，就證明它們存在的合理性。就像在設計的過程中，很多人會將進行條件選擇語句封裝到不同的類的重構，以滿足設計中的”開－閉“原則，這樣做有他的道理。但並不是說以後就不用條件轉移語句了，要不開發語言怎麼會支持條件轉移語法呢。我們要根據具體的情況選擇是否重構，比如我們只需要創建一個對象，如果進行重構，試想得建多少的類啊，維護起來頭不夠大啊。
那是不是在項目開發中就可以任選一種方式呢？當然是不可取，很多都是依據具體情況而定的，只有在具體情況中才能說好還是不好。打個比方，一個項目，好的設計需要1個月，差的設計只要10天，此時你應該選擇哪一個？更多的人會選擇花1個月的設計，因爲大家對設計的追求。但是如果這個項目只給了1個月時間，你又該如何選擇呢？當然，這個例子不是很確切，但只想說明一點：適合纔是正確的。將業務寫入存儲過程，可以找出很多的理由推翻這種做法，也能找很多的理由贊成這種做法，那都是站在不同的項目環境看這個問題。對於小型的項目，邏輯相對簡單，爲了快速，減少開發規模，將業務邏輯寫入存儲過程，是比較好的一種方式；對於大型項目，考慮業務邏輯的複雜性，將業務邏輯封裝到組件中是一種相對較好的方式。相對存儲過程的修改、維護和部署，是否要更安全和方便呢？同時，將業務邏輯寫入存儲過程，會增加數據庫服務器的負荷，極端一點有一個很複雜的邏輯，需要讀取很多的數據進行比較，很多人併發訪問，那我們是否應該考慮一下數據庫服務器的負擔，是否可以將一部分工作放在客戶端或者應用服務端？。要說的太多了，不過要說明的還是一點：適合纔是正確的！
Windows DNA 應用程序通常使用以下三種實現方式中的一種或多種方式來實現其業務邏輯：
| • |
ASP 頁 |
| • |
COM 組件，可能使用 COM+ 提供的其他服務 |
| • |
在 DBMS 中運行的存儲過程 |
一般來講，在 ASP 頁中編寫過多的業務邏輯並不是一個好辦法。因爲必須使用簡單的語言（例如，Microsoft Visual Basic? Script (VBScript)），而且每次執行時都要解釋代碼，這會對性能造成影響。而且 ASP 頁中的代碼不好維護，主要是因爲業務邏輯通常與創建用戶界面的表示代碼混合在一起。
鑑於這種情況，建議在編寫中間層業務邏輯時，將業務邏輯當作 COM 對象來實現。這種方法比編寫純粹的 ASP 應用程序要稍微複雜一點，但是可以使用全功能語言來生成編譯好的可執行文件，因此其結果要快得多。將業務邏輯包裝在 COM 對象中還可以將此代碼與包含在 ASP 頁中的表示代碼完全分隔開來，從而使應用程序更易於維護。
從 COM 到 COM+，其體系結構相差無幾。但是，正如許多 Windows DNA 體系結構設計人員所瞭解的，除非真正需要，否則不應使用 COM+ 提供的核心服務，如事務、實時 (JIT) 激活、基於角色的安全性和線程服務等。使用其他開發平臺提供的 COM+ 或類似服務自然會導致應用程序速度更慢、更復雜。只有在以下情況下使用 COM+ 纔有意義：
| • |
需要跨越不同資源管理器（例如，Microsoft SQL Server(TM) 和 Oracle）的分佈式事務。 |
| • |
應用程序可以有效地利用基於角色的安全性。 |
| • |
可以增強 Microsoft Visual Basic? 6.0 的線程特性。 |
| • |
JIT 激活能夠提高性能；瀏覽器客戶端很少出現這種情況，因爲 ASP 頁是通過 JIT 有效激活的。 |
| • |
COM+ 的配置優勢大大簡化了應用程序的部署。 |
編寫業務邏輯的第三種方式是，創建一些作爲存儲過程在數據庫管理系統 (DBMS) 中運行的代碼。儘管使用存儲過程的主要原因是將數據庫架構的詳細信息與業務邏輯分隔開以簡化代碼的管理和提高安全性，但代碼與數據如此接近也有助於優化性能。那些必須獨立於 DBMS 的應用程序（例如由獨立的軟件供應商創建的應用程序）通常要避免使用這種方法，因爲它會將應用程序鎖定到某個特定的數據庫系統中。存儲過程的編寫和調試可能會比 COM 對象的編寫和調試難，而且此方法會減少重複使用代碼的機會，這是因爲 COM 對象通常比存儲過程更易於重複使用。但是大多數自定義應用程序仍然連接到最初創建它們的 DBMS 上，因此使用存儲過程的性能優勢還是很大的。鑑於這種情況，那些必須儘可能運行良好的 Windows DNA 應用程序通常對部分或全部的業務邏輯都使用存儲過程。