采用標準的架構：描述從低層到高層
首先是系統分析，找出你需要什么功能，然后按照下面的步驟執行：

數據庫層：數據庫層就是SQL語句、數據庫、表、視圖、觸發器等等的創建和管理。這一層和JAVA無關，但是卻是最重要的一層
持久層（Hibernate、JPA、JDBC）：這一層的目的很明確，就是ORM，這里還不用你定義接口和類，你只要使用框架就可以了。
DAO層（Data Access Object）：這一層比較重要點，這里定義的都是對一些最原始的類進行操作的方法
打個比方：

我們有一個Account類，用來表示賬號，那么對應有一個接口

public interface AccountDao 
{
Account create( Account account ); //創建一個Account賬號
void update( Account acconut ); //修改賬號
void delete( int id ); //通過ID刪除Account
void find( int id ); //通過ID找到Account
}

然和我們有具體的實現
public class AccountDaoImplForHibernate implements AccountDao
{
//這里實現AccountDao所有的接口
}

這里要說明一下，為什么要這個DAO層，我直接操縱Hibernate框架去完成不就可以了么？為什么要用一個AccountDao在從中進行阻攔。
這就是Java中接口威力所在，定義了一個接口，你就不用管下面的具體實現是用那個框架實現的，總之實現就可以了。因為軟件的目的是要重用，而在WEB開發中，每個網站都有自己不同的要求，所以也就讓人覺得重用不重用不關我事情：“反正老子就用Hibernate管理數據庫了，下次再開發類似的大不了我重寫，反正又不難。”很明顯，這種思想很實用，似乎馬上就能進行開發，但是這明顯是錯誤的思路。

根據我開發B/S系統的經驗（容我這么說吧，其實我也沒弄過幾個），我喜歡利用Dao層把WEB框架和ORM框架隔離開來進行開發。不知道大家在開發WEB站點的時候有么有覺得，每次修改完一個類都得重新部署，每次部署都得重新加載數據源、連接數據庫、配置持久化框架稀里嘩啦一大堆事情，部署一個項目往往用掉十幾甚至幾十秒。但是如果我們能利用Dao層進行隔離，那么情景就又是另外一個樣子。

我們可以偽造一個數據庫，沒錯，是偽造的，用了HashMap<Integer,Account>對數據庫進行簡單的模擬。具體來說，就是為測試寫一個類去實現AccountDao接口，但是這個類不再連接數據庫，而是直接對偽造的數據庫，也就是HashMap表進行操作

public class AccountDaoImplForTest
{
//具體實現
}

這樣部署起來就快多了。

而對于AccountDaoImplForHibernate的測試，可以通過J2SE應用程序完成，同樣也省下了部署WEB到J2EE服務器的時間。效率第一哈~

順便說說這一層應該拋出的異常。為了屏蔽掉Dao的具體實現，我們很有必要為Dao層自己定義一些異常，用來替代由Hibernate、JDBC他們拋出的異常。這樣對于Dao的上一層Service層來說，只看到Dao的東西，其他什么都沒看見，也不知道這個Dao具體是Hibernate呢還是JPA呢還是JDBC


同樣的道理，我們來看Service層
Service層：在Service層中我們定義這樣的接口
public interface AccountService
{
Account register(Account account); //注冊
Account login( String username, String password ); //登錄
void modify( Account account ); //修改
Account find( int id ); //通過ID獲取Account
Account delete( int id ); //刪除Account
}

乍看之下，似乎Service層和Dao層差不多，無謂就是多幾個方法，那我直接定義到Dao層不可以嗎？答案肯定是不可以，真是廢話，可以我就不寫了。但還是要說說理由：很簡單，Service層隔離了業務需求變化和數據庫之間的關系。也就是說，不管上面的業務邏輯怎么變化，你只用修改Service層的代碼就可以了，Service通過調用Dao來實現對數據庫的操縱，很顯然Dao不知道Service的存在，所以Service怎么變Dao都不用去理會。除非Service提出了Dao沒有實現的要求，比如說Service需要獲取所有賬號的人數，而我們當初在系統分析的時候沒有做好，沒在Dao層預留一個方法去獲取所有賬號的數量，那么這個時候就得被迫修改Dao層了，但是，也僅僅只是修改到Dao層而已，由于Dao層的功勞，你還不必去修改數據庫。

所以說，開始項目之前對整個項目進行詳盡的業務分析對你定接口是有很直接的因果關系的，分析沒做好，那么接口就得整天改，這個時候你還不如不用接口呢~~~

在Service層拋出的異常也有講究：在Service層，我們只能拋出業務邏輯上的異常，像AccountExistedException(賬號已存在)異常啦、UsernameNotFoundException(用戶名沒找到異常)啦等等，這樣Service的上一層就不會感覺到Dao層的存在。

終于到了最后一層：VIEW層
VIEW層：在這一層你不用定接口，你要使用WEB框架的接口、類，至于是STRUTS還是JSF由你定