做設計前期需要注意的細節
數據庫方面：
1、
數據庫設計，所有整數型的字段默認賦值為0（或-1，這個根據業務來就好，不是特別強求），字符型也默認賦值‘’（這個倒可做可不做）。可以避免程序的空指針異常。
詳細例子：
Public class
User{
Private Integer
state;
Public Integer
getState(){
Return state;
}
}
在action層調用時：
User user = new
User();
If(user.getState()>1){
如果數據庫沒有賦初始值的話，就會報空指針異常
//其他業務邏輯
}
2、
把所有冗余字段記錄清楚，下次應用程序修改某字段的時候就要把相應的冗余字段全部修改過來?？梢员苊鈹祿灰恢滦?。
例子：
A表冗余了b表的name字段，c表冗余了b表的name字段。
程序實現有兩種方式解決這種冗余數據：
ü
修改b的name字段的時候就相應的把a和c表的name字段也修改掉
ü
修改b的name字段的時候插入到另外一個表中，通過定時器在凌晨的時候進行自動修改
3、
主外鍵通過數據庫文檔描述清楚，數據庫不直接建立主外鍵關系，最主要是考慮到以后數據庫擴展，建立了主外鍵的話，水平擴展會非常難。
4、
Tinyint類型的數據，應該說明每種類型的用途，例如: 1:刪除 2:未刪除。
5、
某一些初始數據前期就應該固定好，并且備份好。以免以后弄亂了。比如：城市數據都不會變動的數據。
6、
數據庫的數據主要分為基礎數據和業務數據，城市等這些屬于基礎數據，而會員和會員賬號屬于業務數據，業務數據在應用程序中就需要注意了，添加一個會員數據后需要把會員賬號的默認賬號也開起來（當然有些業務規則要求賬號可以后期獨立開啟）。
7、
對于數據庫中“刪除”操作的處理，我們不需要將數據刪除，只要將狀態標識一下即可，比如用戶可以設置一個state狀態，1：啟用 2：禁用 3：刪除
代碼方面：
1、
統一checkstyle和版權申明等注釋。
2、
Action在前期就應該用模塊化方法規定好，同一模塊中公用的部分應該用utils文件來進行共享，避免使用繼承，減少程序過于龐大和復雜化。
3、
業務層之間調用應該使用service，而不是去直接調用dao層。
4、
業務層的代碼特別是update，delete的方法不能直接返回void，應該給出一個特別的值，或者拋出異常，客戶端才能真正的準確知道此次操作是否真正成功。
可能比較模糊，舉一個例子：
前提條件,業務層的代碼如下：
Public void
deleteById(int id){
String sql = “delete
from User where uid=?”;
userDao. executeUpdate(sql);
}
客戶端發起刪除操作，給了一個數據庫不存在的id，而這樣的delete語句是不會報錯的.那么在action層調用這個方法的時候，action層只要沒有拋出異常，那么action只能認為業務層的deleteById方法一定執行成功了，實際對于用戶來說是沒有執行成功這個操作。用戶體驗非常不好。如何改進呢？
Public int
deleteById(int id){
String sql = “delete
from User where uid=?”;
Return userDao. executeUpdate(sql);
}
Action層調用這個方法后，判斷返回的int值判斷是否執行成功，然后把相應的結果反饋給客戶。
另外一種改進方法：
Public void deleteById(int id) throws new
DeleteException{
String sql = “delete
from User where uid=?”;
Int result =
userDao. executeUpdate(sql);
If(result==0){
Throw new DeleteException(“刪除操作失敗”);
}
}
Action層調用這個方法后就一定要捕獲DeleteException異常，那么反饋給客戶的結果也是正確的。
5、
dao層的方法也是類型于上面所講的。
6、
ajax層的ajax方法調用也要注意一點：對于都要加上error方法或者failure方法，因為服務端出問題的時候，有一個很好的提示給用戶，對于用戶體驗來說也是非常好的一種感受。
7、
業務層用例之間的耦合盡量少，但是類似交互規則這樣的場景存在的話如何處理呢，可以通過業務規則來處理，可以減少耦合。