内容：
請問大家是如何處理以下問題：
model是資料庫表的實體映射，當系統的需求出現新的變換，例如增加新的功能時資料庫需要增加新的字段，
或需要去掉和更換某些舊的功能，那麼對應的資料庫字段肯定是會修改的。如果資料庫的表結構有變換，
對應實體model層肯定有變換。
改一個字段，
model層必須要修改，
那麼dal層必須要修改，
sql語句必須要修改，
表示層的資料展現也是依賴model層的屬性名稱，也要修改。
這不符合設計模式的單一職責。牽一發動全身。
并且這樣設計，那用啥設計模式都是白搭。
其次工作量非常大，例如商品表的話 光執行查詢的地方就不得了。
請問大家是如何處理這種問題，或者怎麼把影響降到最低。
文章下面有n多跟貼讨論問題，但實質還沒提出根本的解決之道，或者像有文章裡人說的：
1:樓主問題的根源在于：“model是資料庫表的實體映射”，是以由此進行的所有推導都是錯的
2:需求變更後修改的是模型，不是資料庫！
3:開一貼專門批判一下“資料庫驅動思維”
當然，原貼留言還請看原貼才真實。
下面進行本篇說明：
本篇不對理論性的東西進行相關讨論或解釋，隻想對針這句“怎麼把影響降到最低”，結合cyq.data 架構說說。
不管基于什麼原因，或者是對是錯，一種先資料庫，再實體的方式，已被多數人所接受，并以此方式一直進行着相關的開發。
cyq.data架構如何應對變化：是“怎樣把影響降到最低”的
應對一：枚舉與實體類的引入
對于cyq.data 架構，從本質上來說，是走弱類型的索引方式，是以，是可以不存在枚舉與實體的。
不過為了友善開發，可以引入枚舉與實體，對于本架構所有的相關文章，都采用引入枚舉的方式，是以對于枚舉就不做多介紹了。
以下說下如何引入可應對變化的實體類：
例如users表：
public class users
{
public static int id = 0;
public static string username = "username";
public static int password = 2;
public const int createtime = 3;
}
說明：
從這裡看到，引入的實體和常見的都是屬性的不一樣吧，這裡即可以用靜态屬性，還可以是常量,可以是整型，也可以是字元串。
那具體是怎麼應對的？
假如：将表users的username改成myname,應對的方法當然是改一行代碼就行了,其它調用方式不變：
public static string username = "myname";
有人疑問：如果是把createtime改成logintime呢？你上面定義是整形哦？那你就把它換成：
public const string createtime = "logintime";
對于這種修改，即不用xml對配置，也不用修改其它子產品的内容，隻修改model裡的幾個字就行了。
如果增加字段，一樣了，那你就增加一靜态成員屬性了。
應對二：用autosetpre應對界面上增加與更新的代碼
對于一個屬性的添加與更新，本架構有n種方式了，這裡隻舉例應對的一種。
如果是正常的寫法，我們都會對每個屬性指派，然後才更新如：
maction action = new maction(tablenames.users);
action.set(users.username, "路過秋天");
action.update(2);
action.close();
如果我們盡量使用autosetpre方式，将變化轉到前台ui去，對于字段多的，你還可以省略很多代碼如：
action.setautoprefix("txt");
action.update(2，true);
對于這種方式，隻要前台ui存在textbox并設其id為txtusername即可。
如果此時資料庫username被修改成myname，也隻需要修改前台ui的控件名稱即可,至少修改ui你不用重新編繹代碼。
同樣對于添加資料，你隻需要：
action.setautoprefix("txt","ddl");
action.insert(true);
剩下的事，交給ui處理了。
應對三：視圖與自定義多表sql查詢
視圖：maction支援視圖操作，而且和普通表操作一模一樣，對于視圖的變化，你隻要改了資料庫字段，視圖會自動幫你更新，是以根本不需要處理。
自定義多表的sql：隻需要把自定義多表的sql統一管理，或者在性能要求不高時多用select *方式，即可避免出現字段名稱出現，或者出現了，由于統一管理，你可以很友善的修改并單獨編繹更新，當然了，如果你把它存到或叫映射到xml，那直接修改xml即可，這也是應對方式之一了。
應對四：界面綁定
如果你的界面上采用<%# eval("字段名") %>方式的綁定，在修改完資料庫字段後，你也隻需要修改ui，并不用做編繹處理。
另一種方式如果采用gridview的自動生成列方式，你連ui都省了。
最後結言：
本架構在應對這種資料庫變化方式，适應能力是極強的，關于具體實作方式，有相關開源代碼，各位看官可以直接下源碼研究了。
如果有其它疑問，請留言。
版權聲明：本文原創發表于部落格園，作者為路過秋天，原文連結：
http://www.cnblogs.com/cyq1162/archive/2010/09/19/1830519.html