我們先假設一種情況，乙個開發商想蓋一座大樓（假設30層吧），先要弄乙個設計圖紙呀，沒有設計圖紙怎麼蓋樓呢？設計圖紙的其他部分我們就先不管了，只看看電梯的這一塊的情況。一開始要選用電梯公司a的電梯，於是設計圖就根據a的電梯設計電梯間。圖紙設計完了，開始施工，一切都很順利，很快大樓就蓋起來了，大家都很高興，下面要開始安裝電梯了。但是以外發生了。
原來要採用電梯公司a的電梯，但是由於種種原因不能採購了，於是改用了電梯公司b的電梯，拿到電梯的技術引數大家傻眼了，怎麼b的電梯要比a的電梯長30裡面？這樣太長了，電梯間裡面放不下去呀？怎麼辦？樓都蓋好了，難道要修改電梯間，把每一層的電梯間都加寬嗎？這改動量也太大了呀，如果因此影響了整體的穩定性怎麼辦呀？那麼改電梯間不上上策，看看其他電梯公司的電梯有沒有適合的吧，換電梯還是比較方便的呀，這才是上策！
但是由於電梯間已經設計好了，那麼選擇電梯的範圍就縮小了，尺寸不匹配的，價效比再好也不能選。這個就很被動了。如果所有的電梯公司生產的電梯，外觀尺寸都是一樣的，那該多好呀。這樣設計的時候就不用考慮將來採用什麼樣的電梯了，因為所有的電梯的外觀尺寸都是按照乙個標準生出來的，不用擔心電梯間設計出之後，電梯放不進去的情況。
對於電梯公司來說，這也是一件好事，只要按照這個標準生產電梯，那麼都不用擔心生產出來的電梯安裝不上的情況了。
ps：這個就是所謂的針對介面程式設計吧。不過這裡並不想討論介面程式設計的問題，只是寫到這裡了，突然想到的。這裡想說的是實體類。
好了故事變好了，我不是搞建築的，不知道這個故事編的是否合理。我想說的是，在三層裡面，實體類變化了，每一層如何應對的事情。
我不願意接受三層的形式，一大原因就是當實體類變化的時候，基本每一層都需要改**，就像大樓裡的電梯變長了，每一層的電梯間都要修改一樣。而我又沒有想到什麼好的方式來應對（在使用三層形式的範圍內），所以我就沒有用三層的這種形式開發專案。
針對介面程式設計，看起來很好，那麼如何來實現呢？這個我就不知道了，因為對介面的了解並不多，對實體類在各種業務需求下會變成什麼樣子，「資料」掌握的也不多。看了前兩天園子裡的一篇post，也沒感覺出來有什麼優勢，可能是我還沒有看到真正的好的針對介面程式設計的例子吧。
所以我只好採用笨招了，定義乙個columnsinfobase 類（這裡有介紹）來存放需要的資訊，而columnsinfobase 本身是固定的（屬性不變），就好像限定了長寬高的電梯一樣。這樣每一層都針對這個固定的columnsinfobase 來編寫**，資料層和ui層的**就固定下來了，邏輯層的**變化也不大。單純的字段變化就可以完全不用修改邏輯層了，當然資料層、ui層也是不需要修改的。只有當業務邏輯變化的時候才有可能需要修改邏輯層的**，這時候資料層、ui層的**還是不需要修改的。
dataset與實體類
dataset與sqldataadapter物件是微軟在ado.net中推出的新一代的資料訪問方式，有些情況下非常適合使用 dataset，例如在設計原型 開發小型系統和支援實用程式時。但是，在企業系統中使用 dataset 可能並不是最佳的解決方案，因為對企業系統來說，易於維護要比投入市場的時間更...
「表單控制項」與「實體類」
或許這是一種廣告，但是不得不在這裡寫一下，表單與實體類之間我們經常會做一堆的事情賦值和取值，需要不斷的型別轉換，寫sql語句或者是要和實體類賦值 以及測試等等。這對簡單的新增和刪除 修改來說很即浪費人力，又浪費時間！然而現在，我在keelkit 實現了自動賦值！演示如下 keel.dbhelperd...
建立實體類
下面直奔今天的主題 建立實體類 一點小插曲 接觸abp框架之前，一直都是使用的ef的dbfirst,在那種模式下，我們只要設計好資料庫，然後直接通過模板就生成了實體層，甚至都沒怎麼留意實體層的 是什麼樣子。現在要使用codefirst，就要反過來，先要寫 了，真有點不適應。好吧，為了學好abp，也要...