做设计前期需要注意的细节
数据库方面：
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、
业务层用例之间的耦合尽量少，但是类似交互规则这样的场景存在的话如何处理呢，可以通过业务规则来处理，可以减少耦合。