解剖實體框架 6 總結

1、實體應該要簡單，層次最好平面化，這樣有利於實體在各種通訊中穿越(比如webservices,wcf,remoting,wcf ria等);

2、雖然實體應該平面化，但並不代表不能有繼承層次，因為這種層次可以獲得很多管理和架構的好處

但要注意兩點：1是盡量採用介面 ，而且介面的方法或屬性主要目的是提供統一訪問實體的標準介面

2是屬性的**不要複雜，不要對外依賴，而方法更應該如此，能在操作類或者其它輔助類完成的盡量不要安排在實體類完成。

在整個架構體系中，實體類和系統定義的列舉等常量一樣，應該處於引用的最底層，也就是實體類庫原則上不引用你自己

定義的其它類庫（當然，如果你把系統的常量定義，列舉定義等系統規範性定義放在乙個類庫，實體類庫還是可以引用）。

3、採用根據實體（包括配置檔案）動態構造sql的方式與資料庫互動，雖然大量的減少了資料訪問和轉換類，但也失去了很多靈活性，

如果關聯式資料庫處理更加專業，那還是留給關聯式資料庫去處理。

4、無論什麼框架，資料從介面到資料庫，該幹的事情一件不能少，只是方式不同而已

實體框架提供的資料庫訪問功能，大部分都可以利用autocode工具自動生成，至於快取，很多時候還是需要你自己去維護一部分。

5、成本的減少不是靠乙個框架能解決，如果選擇不當，反而會增加成本。

包括實體框架的學習成本，跟隨成本，一些問題不太好解決的時候，曲線救國的成本等。

6、雖然沒必要從彙編開始做起，但在可選的範圍內，盡量使用較為原始的方式處理會根據永續性。

這主要是針對實體框架的劣勢而言。

7、造船與租船：對於個人選哪個都可以，但對於國家則需要鼓勵造船而不是租船。對於企業，在中國目前的氛圍下，不做討論。

8、專案管理者根據需要造或租，但作為程式設計師，還是多知道點造的技術為好；

9、雖然做技術不一定賺錢，賺錢不一定要技術，但做程式設計師還是要關注點技術，因為這至少暫時是你工作的需要。

整體上來講，如果是專案的規模不是很大，可預見的業務關係不是很複雜，而且公司也不打算走產品路線，那麼採用成熟的實體框架

應該是優先的選擇；如果是個人搞一些系統，那當然是「拿來主義」至上。

在選擇實體框架產品的時候，就我個人的觀點，最好不要用微軟的東西，雖然強大，但夾帶的私貨太多。

後記：在乙個幾乎人人都想一夜暴富的國度，談技術都有些不合時宜....但懲罰卻要開始了...

用市場沒有換來值錢的技術，卻換來了一堆連廁紙都不如的國債...道指暴洩，杯具的卻是我們這些屁民,

奈何？

解剖實體框架 6 總結

1 實體應該要簡單，層次最好平面化，這樣有利於實體在各種通訊中穿越 比如webservices,wcf,remoting,wcf ria等 2 雖然實體應該平面化，但並不代表不能有繼承層次，因為這種層次可以獲得很多管理和架構的好處 但要注意兩點 1是盡量採用介面 而且介面的方法或屬性主要目的是提供統...

解剖實體框架 1 實體與操作類

1 什麼是實體？在我們進行系統構造的目標業務領域裡，有一些物件，主要依賴外界進行管理或者處理，這些物件主要處在被加工或者處理的地位，這樣的物件我們稱之為實體物件，而這類物件以資料為住，一般只具有屬性 或者叫域 不包含或只包含少量的內生方法 主要是一些自我處理的方法，這些方法不會操作其它物件，不產生對...

解剖實體框架 1 實體與操作類

1 什麼是實體？根據我的理解，實體應該是指那些主要依賴外界進行管理或者處理的一類物件，這類物件以資料為住，一般只具有屬性 或者叫域 而不包含或只包含少量的內生方法 主要是一些自我處理的方法，這些方法不會操作其它物件，不產生對其它外界物件的依賴，比如轉殖，格式化等 直白的講，實體就是資料類或者叫結構體...