在最近的幾年裡，很多程式設計師把自己的業餘時間獻給了orm框架的開發，甚至在有些單位的招聘面試中把是否理解或是能否使用一種orm構架，作為了一種評價開發人員技能的必要條件。作為乙個一線的開發工人，我毫不否認orm框架對設計模式社群發展作出巨大的貢獻，以及對提高開發效率這一目標的成果。
在下面的文章中我將簡單的和大家**在大型軟體開發中設計，技術準備，開發，測試修改，生成文件中比較orm構架的資料持久層與採用通用資料持久層(.net ado)的一些不同和其引發的一些問題。
設計階段：
與使用通用的資料持久層相比，orm構架的資料持久層需要專門的技術論證階段，具有以下幾個方面的不同。
通用的資料持久層因為構架在可靠，穩定的商業用開發構架上，所以無需專門的技術論證。
而使用orm構架的資料持久層可能需要專業的技術論證。不管使用什麼框架，出於風險控制的考慮。需要我們對進行框架一系列的完整的驗證，包括可行性,適用度，可靠性，可控制性。
可行性:
我們的專案為什麼要使用orm構架而不是普通的通用資料持久層，改進資料持久層構架的好處在**？開發相率提高，可以提高開發人員的技術能力，企業級別技術的儲備等等這一切是需要我們認真的調查與分析，否則，輕易的選擇使用乙個不被所有人認可的構架是無法說服憂心忡忡的pm的
適用度：
我們所選用orm框架是否完全適用與我們的框架。我們的專案是乙個什麼樣的工程，我們選用的框架是否能滿足專案的需要，是否能滿足預期風險中資料持久層部分的需要，框架的效能資料包表是否是我們可以接受的。這都是我們要關心的。
可靠性：
我們選用的orm框架會不會給我們的風險計畫表上帶來新的附加的風險（使用orm構架已經給我們帶來了乙個新的不小的風險）。框架的bug是否在我們可以接受的範圍內，框架的效能曲線是否已經被把握，免費的框架是否會變成乙個付費的軟體，框架在大規模併發高訪問情況下的效能如何..
可控制性:
orm構架的使用會不會給我們制定開發計畫帶來不可確定因素，我們的開發人員會不會錯誤的判斷在資料持久層上工作需要的時間與資源，人事的異動會不會需要我們付出新的代價來保證開發的繼續進行（新人培訓）
總上所述，應用orm構架的資料持久層除了需要我們打起精神來確認並驗證我們的選擇，可能還涉及需要寫出乙個完整的報告，並舉行乙個大範圍的評審會來說明我們的選擇。
當然，如果是存在企業級的內部 orm框架（這很普遍），或是有了成功的開發例項，我們將很大程度減少這方面的麻煩，但是不可否認的是，相對於使用採用通用資料持久層(.net ado)而言，在設計階段確定使用orm構架，我們確實要付出辛苦的努力與代價的（經驗上來說統一團隊思想，確認使用選定的框架會需要比我們想象的多的時間與精力）。
技術準備：
在這個環節我將闡述一些超出開發組的問題，畢竟乙個專案不只是開發組的事情。
1. 如果確認使用orm構架，那麼我們將無可避免的需要面對開發人員技能的問題。我們的框架使所有的開發人員都會熟練使用嗎？是否需要組織乙個連續的講座並給開發人員乙個專門的學習時間而不是讓他們早早進入開發狀態？我們的boss給我們的時間足夠我們用嗎？
或許在使用企業級元件的情況下，許多構架師慶幸逃過乙個問題。但是要注意到。技術準備的時間不是平白無故的消失了，而是被轉嫁了。而不幸的是，orm構架的培訓也許會在不遠的將來被千刀殺的boss所取消，至少在理論上是存在的。除非boss認為sql基礎隻似培訓相對企業級元件來說簡直不值一提。那，你可以只管使用企業級資料持久層元件了，反正出了事都往他頭上推就是了。^_^
2.在寫這篇文章的時候是2023年的新春，再過幾個月春天就要到了，受夠了公司的開發人員也要蠢蠢欲動了。而對我們的專案而言，這是個無法避免的badtime。新來的夥伴會使用具有我們特色的框架嗎？需要專門的給他來個培訓與指導嗎？這會導致另外乙個（或是幾個）開發人員的抱怨嗎？你認為如何那？
**開發：
經歷了千辛萬苦的準備與設計階段，我們確認了沒有將沒有什麼可以阻擋我們使用我們中意的orm框架並把這個專案完成，那麼我們就經入了開發期。
不得不承認，在這個階段是orm構架的資料持久層將展現自己強大優點的好時機。便捷的開發，清晰的**(作不到這個，選型的構架師基本可以被ko了)使得開發人員體會到了快感。簡單的引發對於構架的反思可以極大的鼓勵開發團隊的學習氣氛與交流，有經驗的領導人甚至會引發一場提高士氣的頭腦風暴。
在資料持久層元件框架上的問題或是缺陷會被迅速的發現並被反饋給元件製作組，這無論是對使用者個人還是元件開發人員都是乙個極好的幫助。
而這上面所描述的一切面對一成不便的ado.net所不能達到的高度。
當然，如果在上面所描述的設計與技術準備階段準備不足的情況下，也可能是乙個完全相反的開發場面。至於有多慘，請讀者自己想象把（你見過恐怖片中的地獄嗎？）。
測試修改：
**的修改：
從專案**的修改上說，orm構架與普通構架的修改很難比較出哪個比較麻煩。orm構架雖然強調的其『對映』能力，但是可惜的是這個『對映』還沒有能夠強到能夠使我們可以完全傻瓜式的修改。
或許有人會提到普通構架那些該死的sql語句與儲存過程的版本是在很難管理，可是我們也無法迴避orm中常遇到的一大堆配置檔案和實體類。或許普通構架在這裡不如orm構架，但是至少他們相距的不是很大，至少沒下面我所要說的差距大。
效能問題：
orm構架最令人詬病的是他的效能問題，儘管各類orm框架都聲稱自己的效能已經很不錯了，儘管orm使用了一系列的新概念來彌補，但是我們仍未發現可以接近ado.net資料的orm框架，這是orm的致命傷。
設想一下：如果我們的專案出現了意外，實際能夠支配的伺服器比預期的要少，我們的壓力計算公式有一些小小的偏差，需要我們提供更好的訪問性？
如果是普通的資料持久層，我們可以馬上進行進行效能優化。
在常見的一些情況下基本不需要改動業務系統，只需要申請專業的資料庫分析與優化師來指導修改就可以滿足要求。
但是如果我們是orm構架那？
我們的orm框架自動生成的**支援資料優化嗎？我們的資料庫分析與優化師能夠理解並提供優化方案嗎？
我們該如何那，是大換血式的更換資料持久層（換用普通的資料持久層會換來很大的提高）還是選擇在別的地方苦苦掙扎以換的小小的效能提公升？
god，我們如何作，才能換來幸福的生活那！
或許我們可以說大型軟體開發中，充足的經費和怪獸級的伺服器可以使我們無視這些效能損失。但是為什麼不把它們剩下來換取更好的選擇那（一次允許攜帶家人的新馬泰雙飛遊）？
負載控制：
orm構架還有乙個問題就是我們無法很好的調節資料庫伺服器與業務系統資料庫的壓力。orm強調的是對映的實現，而非對映的互動支援力度很小。這就使我們很難調節資料庫伺服器與業務系統資料庫的壓力。
比如我可以把業務系統（或資料庫）上的排序，關聯或是複雜計算交給資料庫（或業務系統）來計算，這在普通型資料持久層上只需要簡單的修改**即可實現，但是在orm構架下卻較難實現（需要消耗更多資源）。
生成文件：
當專案交接或是專案完結，orm構架給我們的文件書寫帶來了一些特別的感受。
如果我們選用的orm框架是有使用配置檔案的話，那更要恭喜一聲。^_^
綜上，我們可以看到，orm框架在給我們帶來概念衝擊的時候，在大型軟體開發中使用orm構架，在給我們帶來新的技術體驗與效率上提高的同時，也給我們帶來了一些不同於以往的全新的變化。認識並把握這些變化這些變化是作為乙個開發/構架人員所必須的。
或許上面列舉的在大多數讀者看來很簡單，或是有許多人有不同的意見。但是類似上面的分析，確是我們在構架時不可掉以輕心或是一帶而過的。
因為不正確的認識或是一時的衝動而失去對整體的把握是作為任何乙個開發/構架人員的大忌。如果僅憑技術上的優勢而不顧一切的使用其，將帶來不可預知的風險與代價，而這確實乙個開發/構架人員所很難克制的慾望。
軟體開發的MVC構架
mvc ide開發環境開發時，無意中使用的軟體結構.於wikipedia 軟體的層次劃分 框架 元件 設計模式 演算法與資料結構.模型 model 資料模型 model 用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。模型 有對資料直接訪問的權力，例如對資料庫的訪問。模型 不依賴 檢視 ...
軟體開發總結 需求與開發
需求不是越多越好，也不是越詳細越好。使用者價值是不允許討論 妥協 的，具體實現方案是允許討論 妥協 的。實現和預想之間可能存在差距 例如時間，複雜度，難度，可能性 所以開發人員應該也是需求參與者，負責向需求提出者反饋這些問題，以利於需求提出者做出進一步決策。一是完備性 需求需要明確為什麼樣的使用者提...
房子裝修與軟體開發
忽然發現裝修和軟體開發之間竟然那麼的相識，於是乎我就想把軟體開發的流程貫徹到裝修過程中，希望三個月後由於裝修流程的改進，我的裝修效果能較好的滿足客戶 我 的需求。裝修的平面方案花了三天的時間，首先讓設計師了解房子的基本情況以及我們的基本要求，然後共同協商，製作出平面方案，也就是相當於軟體開發的概要設...