前前後後，花了大約一個周的時間學習ADO.NET Entity，問題一直都很多。學習的出發點是希望瞭解和掌握這門技術，提高開發的效率。但學下來感覺非常彆扭，以是痛定思痛，決定好好研究下ADO.NET Entity的設計出發點和要達到的目標以是有了這篇文章。
現做一個簡單的總結，希望對後來者有幫助，而不是一來就跟着代碼走，結果把自己搞暈。
ADO.NET Entity 推出的關鍵是解決OO程序設計和關係數據庫之間阻抗失諧，可參考網址：
http://msdn.microsoft.com/zh-cn/library/aa730866(VS.80).aspx#EGAA
http://msdn.microsoft.com/zh-cn/library/aa697427%28v=VS.80%29.aspx
http://msdn.microsoft.com/zh-cn/magazine/dd263098.aspx
這個聽起來很美的技術在我實踐後，發現並非如此。
1、爲什麼有阻抗失諧，而不是說關係數據的組織存儲有問題或是面向對象編程有問題？
回答這個問題有點難，如果這兩個問題中任何一個確實存在問題，那麼都對現有的整個計算機系統提出巨大挑戰。所以我先認爲阻抗失諧是存在的。
2、什麼是阻抗失諧：
在現代程序開發中，面向對象的方法論需要自上而下的進行系統實現（業務需求->面向對象的設計和建模->數據存儲），而最終對象數據被存入關係數據庫時由於兩者針對的問題域不同導致的匹配問題稱爲阻抗失諧（例如關係數據庫無法保存OO的封裝、繼承和多態）。
通俗的說：食古不化的關係數據庫存儲方式拖住了宇宙第一帥哥面向對象系統設計和開發的後腿。這有一個時髦的稱呼：叫阻抗失諧。
3、阻抗失諧的表現方式：
3.1、在程序語言中出現編譯器無法理解和調試的SQL字符串，及訪問SQL結果集的字段名字符串
3.2、我們需要的是對象、但我們得到的是一個二維表
4、阻抗失諧問題的本質
考慮一下：從ODBC數據訪問技術到阻抗失諧問題被公佈並認同前，我們是怎麼生活阻抗失諧這個問題中？以是我發現，在這個問題被認同前，處理問題的流程和方式是：
業務需求->關係數據建模->程序實現。於是：阻抗失諧問題消失了。在程序中出現SQL語句和二維表是應該的
個人認爲阻抗失諧問題的本質是：採用什麼方式來實現軟件系統帶來的問題。以數據庫建模爲主導、程序實現的方式，沒有這個問題。以OO方式爲主導，把數據庫完全看爲一種存儲需求的方式，存在阻抗失諧。
5、是否選擇ADO.NET Entity
問題討論到現在、變成了一個類是先有雞還是先有蛋的問題。但我們不應該在這個問題上糾纏。
如果你想從業務需求->面向對象的設計和建模->數據存儲的方式來完成系統，那麼可以考慮使用並開始學習並使用ADO.NET Entity。
如果你已經習慣了業務需求->關係數據建模->程序實現的開發方式，那麼我不建立你學習和使用ADO.NET Entity。因爲現有的方式ADO.NET支持的很好，而且一個完整的軟件產品或經歷了幾年數據庫應用程序開發的程序員應該已經有了很多與DB交互和管理代碼而不只是簡單有幾條SQL或是一個DBHelper這樣的東西，在轉移代碼時，學習成本和代碼轉移存在風險。
6、現在網上能搜到關於ADO.NETEntity的文章中，存在如下問題
1、大談阻抗失諧、有誇大問題的成份。誰都不是銀彈，我想這一點大家都明白
2、有意隱藏效率問題而誇大程序代碼的直觀和簡潔性，完成ORMapping是需要硬件和時間成本的，新的語言表達方式也需要學習成本（事實上我立即看懂了存在阻抗失諧的代碼，但沒有立即看懂那些被稱爲更直觀簡潔的代碼），對於複雜或大數據量的系統如何使用，並沒有正面回覆。最後：我採用的是業務需求->關係數據建模->程序實現的開發方式。這也是我越學越彆扭的原因。
所以ADO.Entity。再見。