預存程序已經失去了一些組織的歡心好幾年了。現在這些企業存取其資料庫的首選方法是使用物件關係對映（Object-relational Mapper，簡稱 ORM），例如 NHibernate 或 Entity Framework。在接下來的幾篇文章中，我們將探討他們為什麼這樣做，以及這種模式轉變是否表示預存程序最終會被淘汰。
預存程序基礎
如了解關聯式資料庫的預存程序和函式中所述：
預存程序（stored procedure，簡稱 proc）是一組有指定名稱的結構化查詢語言（Structured Query Language，SQL）語句，作為一個群組儲存在關聯式資料庫管理系統中，因此可以被多個程式重用和共用。預存程序可以存取或修改資料庫中的資料，但它不依賴於特定的資料庫或物件。這種不緊密結合的情況是有利的，因為為不同但相似的目的重用程序是非常容易。很易為不同但相似的目的而重用程序。
到目前為止，聽起來預存程序像是一個有用的工具，但正如我們將在下一節中看到的那樣，並不是每個人都相信這一點。
預存程序的缺點
儘管預存程序有其長期以來的優勢，但預存程序的反對者指出了其許多缺點，例如：
- 容易出現錯誤：由於應用程式邏輯封裝在預存程序，因此應將其移到應用程式程式碼中，以便更好地管理和測試。由於測試預存程序本身就是個挑戰，它們可能是導致一些非常嚴重錯誤的原因。
- 實作差異：預存程序實作因供應商而異。許多資料庫開發人員認為 Oracle 的預存程序質量最高，而其他產品的程序（例如 MySQL 的預存程序）不太完善。
- 不斷變化的需求：預存程序的原本用途之一是減少網路流量。然而，在現今超快的網路速度下，這已不是問題了。因此，將應用程式邏輯放入預存程序可能是過早最佳化。
- 難以維護：預存程序往往需要比應用程式程式碼更多的工作來開發和維護。對於初學者，你需要有不同的預存程序來為每個資料表執行建立、擷取、更新和刪除作業，並為你希望進行的每個不同查詢建立一個個別的預存程序。然後，你需要在程式碼中實作類別和/或方法來呼叫每個預存程序。與之相比，O/R 對映只需要類別定義、資料庫資料表和對映檔案。事實上，現代 ORM 使用以慣例為基礎的方法，無需個別的對映定義。
- 程式碼重複：預存程序要求你違反 DRY（Don't repeat yourself，不要重複你自己）原則，因為你必須參考資料庫資料表欄六次或以上。此外，將物件作為參數傳遞至大多數預存程序是不可能的，只有字串、整數、日期/時間等簡單類型，所以避免很長的參數清單幾乎不可能（十幾個或以上是常見的！）。
即使是預存程序最堅定的反對者，在某些情況下仍然使用它們。例如，預存程序非常適合用於資料庫內部管理或報告。否則，開發人員應該有充分的理由將它們整合到他們的應用程式中。
預告
聽過一些避免預存程序而推薦應用程式程式碼和物件關係對映（ORM）（例如 NHibernate 或 Entity Framework）的原因後，你可能會確信這是正確的。好吧，暫時不要做出決定。在下一部分中，我們將考慮放棄和保留預存程序的更多動機因素。然後，如果你仍然想改變，至少你將對所涉及的所有問題有更全面的了解。
