PLSQL學習-【9包】

                   部署方便，包頭只是宣告，包體實際程式碼。

對於重要的儲存過程我們建議從包中拿出來單獨的進行編譯。


一下部分為摘抄--
今天，和一個朋友聊天，他是做.NET開發的（PS:鄙人是 Java 的虔誠信徒），朋友說他們最近在做的一個專案，使用了400個左右的儲存過程程式碼封裝了整個邏輯!光是儲存過程程式碼在50000行左右!由此引發了我對軟體開發的一些思考，我在此只是拋磚引玉，歡迎大家參與討論！

    現代軟體開發為什麼要分三層甚至n層，無非是為了實現“強內聚、松耦合”的目標，將軟體“分而治之”，把問題劃分開來各個解決，易於控制，易於實現元件重用，易於擴充套件和維護，易於分配資源。大大降低了開發和維護的成本，其優勢不言而寓。

    以下是鄙人的一些愚見，有不對的地方望指正！

    1. 對於小專案，業務放儲存過程裡程式設計最簡單，詳細寫好註釋，避免資料從資料庫到程式的來回傳遞，這也是儲存過程的優點。
    2. 但是對於中大型專案，訪問量很大，若將業務邏輯大量封裝於儲存過程中會導致資料庫壓力太大，中間層壓力太小，資源閒置。這時就應該把業務放到中間層，中間層壓力大的時候容易做伺服器Cluster，做負載平衡。
    3. 做產品的時候，考慮到產品的移植性和安全性，應該儘量避免儲存過程。
    4. 多人開發的時候，儲存過程不是很方便做版本控制和管理。
    5. 關於Debug，除錯不是很方便。
    6. 如果sp中有一大堆if, case, 然後每個begin  end之間有一大段處理, 甚至if case 還不斷巢狀, 我認為這是在濫用sp, 這個應該是程式去完成的；    
      如果程式中從資料庫中不斷的拉資料和快取資料,   結果就是為了幾個表關聯出點什麼東西,   我認為是在濫用程式,   這個應該是sp去完成的

    7.儲存過程的執行效率確實比較高，一些O/R mapping 框架如Hibernate則有效能瓶頸問題，用得不好會導致效能的下降，個人認為用ibatis 再在適當的時候結合使用儲存過程，這樣既可以兼顧OO的設計，又可以兼顧效能問題。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

對於開發者而言，耦合原則表示程式中單個的模組應該儘可能的獨立。 
處理一個模組時，不應該依賴另一個模組的內部工作。 
內聚原則是指，在一個給定的模組內部，所有的程式碼應該只完成一個單個的目標。 
IT界有一句很著名的口號： 強內聚、松耦合 。 
即使是最初級的程式設計師，在常常的被教導中，他也瞭解了這句口號的含義：我們的程式要模組化，模組要完成明確的一組關聯的服務功能，要求它的各部分是相關 的、有機組合起來是完整體（外部程式來看黑盒子），模組的內部各成分之間相關聯程度要儘可能高（強內聚）；而模組與模組之間又要求是可分拆的、少依賴的 （松耦合）。 
人們易於實現強內聚的模組，例如：一個函式實現一個獨立的功能，這就是強內聚。 
人們不易實現松耦合，因為，孤獨的模組毫無意義，只有模組間的相互協調地工作，才能實現系統的目的。而對於模組間的相互關係的設計，沒有一定的經驗是難以 把握。耦合的強度依賴於：（1）一個模組對另一個模組的呼叫；（2）一個模組向另一個模組傳遞的資料量；（3）一個模組施加到另一個模組的控制的多少； （4）模組之間介面的複雜程度。等等。 
當然，“強內聚、松耦合”也是有矛盾的，如：內聚性越強，則要求的函式越多（每個函式只作一件“事”），這樣，將它們組合成“大”的功能，也就越複雜，就 不可能達到松耦合。因此，應在二者之間作出平衡與折衷的選擇，這也體現程式設計師的水平。從系統論的角度來看，系統是有層次的，即系統可以分為子系統，模組可 分為子模組，“強內聚、松耦合”的“度”的把握，應結合系統的次層性來考慮，即通常應在層次性上作出折衷，如：模組內子程式（下一個層次上）應共享資料 （有一定的耦合度），而減少全域性變數能降低子程式性間的耦合性。 
物件導向的語言進一步強化了“強內聚、松耦合”，類的封裝性既強調了相關內容（資料及其操作）的內聚，又強調了類的獨立性和私密性。而類的繼承性以及友元 等，就是在松耦合的原則下規範了類之間的關聯關係。類與類之間通常透過介面的契約實現服務提供者/服務請求者模式，這就是典型的松耦合。 
“強內聚、松耦合”對於程式編寫分工、程式的可維護性以及測試都有重要的關係，如：從設計角度來看，在“強內聚、松耦合”的指導下進行的設計得到的程式模 塊，符合專案管理的WBS（工作分解結構）的要求，其相對獨立的模組可以分配到具體的程式設計師進行開發，另外，程式編碼外包也必須建立在這種原則的設計之 下；從程式生命期角度來看，它有利於提高程式質量，特別是方便於程式的日後維護，即程式模組的相對獨立性是可維護性的保證；再從測試角度來看，符合“強內 聚、松耦合”的程式，易於對區域性（模組）進行黑盒測試，也易於編寫測試用的“樁”和“驅動”。 
“強內聚、松耦合”也是對組織結構的要求，專案組分為幾個小組（正式的或非正式的），各小組的工作應是高度相關的，各小組之間的工作應儘量是較少相關或有 明確的介面，從而減少溝通成本。其實，“強內聚、松耦合”是系統中應遵守的普遍原則，我們在許多領域都可以找到它的應用。 
“強內聚、松耦合”是我們不得不念的“三字經”，我們一定要念好它。