1、實體應該要簡單，層次最好平面化，這樣有利于實體在各種通信中穿越(比如Webservices,WCF,Remoting,WCF RIA等); 2、雖然實體應該平面化，但并不代表不能有繼承層次，因為這種層次可以獲得很多管理和架構的好處 但要注意兩點： ????? 1是盡量采用接口，而且接口的方法或屬性主要目的是提供統一訪問實體的標準接口 ????? 2是屬性的代碼不要復雜，不要對外依賴，而方法更應該如此，能在操作類或者其它輔助類完成的盡量不要安排在實體類完成。 ??? 在整個架構體系中，實體類和系統定義的枚舉等常量一樣，應該處于引用的最底層，也就是實體類庫原則上不引用你自己 ???? 定義的其它類庫（當然，如果你把系統的常量定義，枚舉定義等系統規范性定義放在一個類庫，實體類庫還是可以引用）。 3、采用根據實體（包括配置文件）動態構造SQL的方式與數據庫交互，雖然大量的減少了數據訪問和轉換類，但也失去了很多靈活性， ???? 如果關系數據庫處理更加專業，那還是留給關系數據庫去處理。 4、無論什么框架，數據從界面到數據庫，該干的事情一件不能少，只是方式不同而已 ???? 實體框架提供的數據庫訪問功能，大部分都可以利用AutoCode工具自動生成，至于緩存，很多時候還是需要你自己去維護一部分。 5、成本的減少不是靠一個框架能解決，如果選擇不當，反而會增加成本。 ???? 包括實體框架的學習成本，跟隨成本，一些問題不太好解決的時候，曲線救國的成本等。 6、雖然沒必要從匯編開始做起，但在可選的范圍內，盡量使用較為原始的方式處理會根據持久性。 ???? 這主要是針對實體框架的劣勢而言。 7、造船與租船：對于個人選哪個都可以，但對于國家則需要鼓勵造船而不是租船。對于企業，在中國目前的氛圍下，不做討論。 8、項目管理者根據需要造或租，但作為程序員，還是多知道點造的技術為好； 9、雖然做技術不一定賺錢，賺錢不一定要技術，但做程序員還是要關注點技術，因為這至少暫時是你工作的需要。 整體上來講，如果是項目的規模不是很大，可預見的業務關系不是很復雜，而且公司也不打算走產品路線，那么采用成熟的實體框架 應該是優先的選擇；如果是個人搞一些系統，那當然是“拿來主義”至上。 在選擇實體框架產品的時候，就我個人的觀點，最好不要用微軟的東西，雖然強大，但夾帶的私貨太多。 后記：在一個幾乎人人都想一夜暴富的國度，談技術都有些不合時宜....但懲罰卻要開始了... 用市場沒有換來值錢的技術，卻換來了一堆連廁紙都不如的國債...道指暴泄，杯具的卻是我們這些屁民, 奈何？