具體pdf的下載地址：
分離數(shù)據(jù)庫訪問，UI和域邏輯
http://wingel.javaeye.com/topics/download/ce15b67a-1df7-4a75-8f03-1a505aca35d8
請從鏈接中下載，下面的內(nèi)容只是摘要。
處理三種類別的代碼都混在了一起：
?? 1.UI: JDialog, JTextField, 響應用戶事件的代碼。
?? 2.數(shù)據(jù)庫訪問: Connection, PreparedStatement, SQL statements, ResultSet 等等。
?? 3.域邏輯: 參會者的默認id，參會者的名字必填，所屬地區(qū)的限制等等。域邏輯又稱為“域模型”或者“業(yè)務邏輯”。
這三個不同類別的代碼混在一起，會造成下面的問題：
1.代碼很復雜。
2.代碼很難重用。如果我們想創(chuàng)建一個EditParticipantDialog，讓用戶更改參會者的信息，我們就想重用部分域邏輯（比如，地區(qū)的限制）。但實現(xiàn)這部分域邏輯的代碼跟AddParticipantDialog混在了一起，根本不能重用。如果是在一個web系統(tǒng)中，就更難重用了。
3.代碼很難測試。每次要測這樣的一段代碼，我們都要建一個數(shù)據(jù)庫，還要通過一個用戶操作界面來測試。
???? 4.如果數(shù)據(jù)庫表結(jié)構(gòu)更改了，AddParticipantDialog這個類，還有其他的很多地方都要跟著更改。
5.它導致我們一直在考慮一些低層的太細節(jié)的概念，比如數(shù)據(jù)庫字段，表的記錄之類的，而不是類，對象，方法和屬性這一類的概念?；蛘哒f白了一點，一直在考慮怎么往數(shù)據(jù)庫里面裝數(shù)據(jù)，而沒有了面向?qū)ο蟮母拍?，沒有了建立業(yè)務模型的思維。
因此，我們應該將這三種類別的代碼分離開（UI，數(shù)據(jù)庫訪問，域邏輯）。????????