Java开发手册与规范

企业Java开发手册与规范

本文的愿景是“码出高效、码出质量”；宗旨是编写出简洁、可靠、高效、可移植维护的代码，以提高产品的质量。每行代码的字里行间最终都会影响软件的质量，质量的提升是尽可能少踩坑，少冗余，多规范。现代软件架构都需要协同开发完成，以一种普遍认可的统一方式来提高协作效率；所谓无规矩不成方圆，无规范不能协作。

目录

一、编程规约

(一) 命名风格

(二) 常量定义

(三) 代码规范

I  OOP

II  集合

III  并发处理

IV  控制语句

V  其它

(四) 异常处理

(五) 日志规约

二、MySQL 数据库

(一) 建表规约

(二) 索引规约

(三) SQL 语句

三、工程结构

(一) 应用分层

---

一、编程规约

(一) 命名风格

1. 【强制】 代码中的命名均不能以下划线、美元等符号开始和结束。

2. 【强制】 代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。

说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义；杜绝完全不规范的缩写，避免望文不知义。

3. 【强制】类名使用 UpperCamelCase 风格，必须遵从驼峰形式。

4. 【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从 驼峰形式。

5. 【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。

6. 【强制】抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类 命名以它要测试的类的名称开始，以 Test 结尾。

7. 【强制】中括号是数组类型的一部分，数组定义如下：String[] args;

反例：使用 String args[]的方式来定义。

8. 【强制】POJO 类中布尔类型的变量，都不要加 is，否则部分框架解析会引起序列化错误。

反例：定义为基本数据类型 Boolean isDeleted；的属性，它的方法也是 isDeleted()，RPC框架在反向解析的时候，“以为”对应的属性名称是 deleted，导致属性获取不到。

9. 【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。

10. 【推荐】如果使用到了设计模式，建议在类名中体现出具体模式。

正例：public class OrderFactory; public class LoginProxy;

11. 【推荐】接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁 性，并加上有效的 Javadoc 注释，尽量不要在接口里定义变量。

12. 【强制】接口和实现类的命名基于 SOA 的理念，对于 Service 和 DAO 类，暴露出来的服务一定是接口，内部的实现类用 Impl 的后缀与接口区别。

正例：CacheServiceImpl 实现 CacheService 接口。

13. 【参考】枚举类名建议带上 Enum 后缀，枚举成员名称需要全大写，单词间用下划线隔开。

14. 【参考】各层命名规约：

A) Service/DAO 层方法命名规约

1） 获取单个对象的方法用 get 做前缀。

2） 获取多个对象的方法用 list 做前缀。

3） 获取统计值的方法用 count 做前缀。

4） 保存的方法用 save做前缀。

5） 删除的方法用delete 做前缀。

6） 修改的方法用 update 做前缀。

B) 领域模型命名规约

1） 数据传输对象：xxxDTO

2） 展示对象：xxxVO

3） POJO 是 DO/DTO/BO/VO 的统称，禁止命名成 xxxPOJO。

 

 

(二) 常量定义

 

1. 【强制】long 或者 Long 初始赋值时，必须使用大写的 L，小写容易跟数字1混淆。

2. 【推荐】不要使用一个常量类维护所有常量，应该按常量功能进行归类。如：缓存 相关的常量放在类：CacheConsts 下；系统配置相关的常量放在类：ConfigConsts 下。

3. 【推荐】常量的复用层次：跨应用共享常量、应用内共享常量、子工程内共享常量、包 内共享常量、类内共享常量。

正例：

1） 子工程内部共享常量：即在当前子工程的 consts 目录下。

2） 包内共享常量：即在当前包下单独的 consts 包下。

3） 类内共享常量：直接在类内部 private static final 定

(三) 代码规范

I  OOP

1. 【强制】所有的覆写方法，必须加@Override 注解。

2. 【强制】不能使用过时的类或方法。

说明：java.net.URLDecoder 中的方法 decode(String encodeStr) 这个方法已经过时，应 该使用双参数 decode(String source, String encode)。

3. 【强制】Object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals。

正例： "test".equals(object);

反例： object.equals("test");

说明：推荐使用 java.util.Objects#equals

4. 【强制】所有的相同类型的包装类对象之间值的比较，全部使用 equals 方法比较。

说明：对于 Integer var = ? 在-128 至 127 范围内的赋值，Integer 对象是在 IntegerCache.cache 产生，会复用已有对象，这个区间内的 Integer 值可以直接使用==进行判断，但是这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象，这是一个大坑， 推荐使用 equals 方法进行判断。

反例：

Integer n1 = new Integer(47);
Integer n2 = new Integer(47);
Integer n3 = 47;
Integer n4 = 47;
Integer n5 = 200;
Integer n6 = 200;
System.out.println(n1 == n2);   //false，两个new的对象
System.out.println(n1 == n3);   //false  n1在堆中，n3指向IntegerCache缓存
System.out.println(n3 == n4);   //true   都指向缓存中同一个对象
System.out.println(n5 == n6);   //false  超出缓存范围，分别是两个new出来的对象

5. 【推荐】基本数据类型与包装数据类型的使用标准如下：

1） 【强制】所有的 POJO 类属性必须使用包装数据类型。

2） 【强制】RPC 方法的返回值和参数必须使用包装数据类型。

3） 【推荐】所有的局部变量使用基本数据类型。

说明：POJO 类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何NPE 问题，或者入库检查，都由使用者来保证。

正例：数据库的查询结果可能是 null，因为自动拆箱，用基本数据类型接收有 NPE 风险。

 

6. 【强制】定义 DO/DTO/VO 等 POJO 类时，不要设定任何属性默认值。

反例：POJO 类的 gmtCreate 默认值为 new Date();但是这个属性在数据提取时并没有置入具 体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。

7. 【强制】序列化类新增属性时，请不要修改 serialVersionUID 字段，避免反序列失败；如 果完全不兼容升级，避免反序列化混乱，那么请修改 serialVersionUID 值。

8. 【推荐】POJO 类必须写 toString 方法。

说明：在方法执行抛出异常时，可以直接调用 POJO 的 toString()方法打印其属性值，便于排查问题。

9. 【推荐】循环体内，字符串的连接方式，使用 StringBuilder 的 append 方法进行扩展。

说明：反编译出的字节码文件显示每次循环都会 new 出一个 StringBuilder 对象，然后进行 append 操作，最后通过 toString 方法返回 String 对象，造成内存资源浪费。

反例：

String str = "start";
for (int i = 0; i < 100; i++) {
  str = str + "hello";

}

 

10. 【推荐】final 可以声明类、成员变量、方法、以及本地变量，下列情况使用 final 关键字：

1） 不允许被继承的类，如：String 类。

2） 不允许修改引用的域对象，如：POJO 类的域变量。

3） 不允许被重写的方法，如：POJO 类的 setter 方法。

4） 不允许运行过程中重新赋值的局部变量。

5） 避免上下文重复使用一个变量，使用 final 描述可以强制重新定义一个变量，方便更好 地进行重构。

11. 【推荐】类成员与方法访问控制从严：

1） 如果不允许外部直接通过 new 来创建对象，那么构造方法必须是 private。

2） 工具类不允许有 public 或 default 构造方法。

3） 类非 static 成员变量并且与子类共享，必须是 protected。

4） 类非 static 成员变量并且仅在本类使用，必须是 private。

5） 类 static 成员变量如果仅在本类使用，必须是 private。

6） 若是 static 成员变量，必须考虑是否为 final。

7） 类成员方法只供类内部调用，必须是 private。

8） 类成员方法只对继承类公开，那么限制为 protected。

 

II  集合

1. 【强制】ArrayList 的 subList 结果不可强转成 ArrayList。

2. 【强制】使用集合转数组的方法，必须使用集合的 toArray(T[] array)，传入的是类型完全 一样的数组，大小就是 list.size()。

正例：

List<String> list = new ArrayList<String>(2); 
list.add("guan");
list.add("bao");
String[] array = new String[list.size()]; 
array = list.toArray(array);

反例：直接使用 toArray 无参方法存在问题，此方法返回值只能是 Object[]类，若强转其它 类型数组将出现 ClassCastException 错误。

3. 【强制】使用工具类 Arrays.asList()把数组转换成集合时，不能使用其修改集合相关的方 法，它的 add/remove/clear 方法会抛出 UnsupportedOperationException 异常。

 说明: asList 的返回对象是一个 Arrays 内部类，并没有实现集合的修改方法。Arrays.asList 体现的是适配器模式，只是转换接口，后台的数据仍是数组。

String[] str = new String[] { "a", "b" }; List list = Arrays.asList(str);

第一种情况：list.add("c"); 运行时异常。

第二种情况：str[0] = "gujin"; 那么 list.get(0)也会随之修改。

 

4. 【强制】泛型通配符<? extends T>来接收返回的数据，此写法的泛型集合不能使用 add 方 法，而<? super T>不能使用 get 方法，做为接口调用赋值时易出错。

5. 【强制】集合不要在 foreach 循环里进行元素的 remove/add 操作；remove 元素请使用 Iterator方式，如果并发操作，需要对 Iterator 对象加锁。

正例：

//集合元素删除的正确方式：
Iterator<String> it = a.iterator(); 
while (it.hasNext()) {
  String temp = it.next(); 
  if (删除元素的条件) {
    it.remove();
  }
}
/Java8 推荐使用removeIf()
// map根据value去判断删除
map.values().removeIf(value -> value.contains("1"));
// map根据key删除
map.keySet().removeIf(key -> key != 1);
//map通过entrySet()方法获得值去删除
map.entrySet().removeIf(entry -> entry.getKey() == 1);

// list元素删除
list.removeIf(obj->obj.getId()==1);  //删除list里对象id==1的元素

反例：

List<String> a = new ArrayList<String>(); 
a.add("1");
a.add("2");
for (String temp : a) {
    if ("1".equals(temp)) { 
      a.remove(temp);

    }
}

6. 【推荐】Map类使用 entrySet 遍历  ，而不是 keySet 方式进行遍历。

 说明：keySet 其实是遍历了 2 次，一次是转为 Iterator 对象，另一次是从 hashMap 中取出

key 所对应的 value。而 entrySet 只是遍历了一次就把 key 和 value 都放到了 entry 中，效 率更高。如果是 JDK8，使用 Map.foreach 方法。

正例：

System.out.println("----------------Before JAVA8 ------------------------------");
for (Map.Entry<String, Object> entry : map.entrySet()) {
  System.out.println("key:value = " + entry.getKey() + ":" + entry.getValue());
}
System.out.println("---------------------JAVA8 ------------------------------");

map.entrySet().forEach(entry -> System.out.println("key:value = " + entry.getKey() + ":" + entry.getValue()));
//jdk8  map遍历：
map.forEach((k, v) -> {System.out.println("key:value = " + k + ":" + v);});

//jdk8   list 遍历：
list.forEach(obj->System.out.println(obj.getName()+obj.getId()) );

 

7. 【推荐】高度注意 Map 类集合 K/V 能不能存储 null 值的情况，如下表格：

 

集合类	Key	Value	Super	说明
Hashtable	不允许为 null	不允许为 null	Dictionary	线程安全
ConcurrentHashMap	不允许为 null	不允许为 null	AbstractMap	分段锁技术
TreeMap	不允许为 null	允许为 null	AbstractMap	线程不安全
HashMap	允许为 null	允许为 null	AbstractMap	线程不安全

8. 【参考】利用 Set 元素唯一的特性，可以快速对一个集合进行去重操作，避免使用 List 的contains 方法进行遍历、对比、去重操作。

 

III  并发处理

1.【强制】获取单例对象需要保证线程安全，其中的方法也要保证线程安全。

 说明：资源驱动类、工具类、单例工厂类都需要注意。

2.【强制】线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。

 说明：使用线程池的好处是减少在创建和销毁线程上所花的时间以及系统资源的开销，解决资 源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者 “过度切换”的问题。线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式。

 

3. 【强制】SimpleDateFormat 是线程不安全的类，一般不要定义为 static 变量，如果定义为

static，必须加锁，或者使用 DateUtils 工具类。

说明：如果是 JDK8 的应用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar， DateTimeFormatter 代替 Simpledateformatter

4. 【强制】高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能 锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。

 说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用 RPC 方法。

5. 【强制】对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会造 成死锁。

说明：线程一需要对表 A、B、C 依次全部加锁后才可以进行更新操作，那么线程二的加锁顺序 也必须是 A、B、C，否则可能出现死锁。

 

6. 【强制】并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加 锁，要么在数据库层使用乐观锁，使用 version 作为更新依据。

 说明：如果每次访问冲突概率小于 20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次 数不得小于 3 次。

7. 【强制】多线程并行处理定时任务时，Timer 运行多个 TimeTask 时，只要其中之一没有捕获 抛出的异常，其它任务便会自动终止运行，使用 ScheduledExecutorService 则没有这个问题。

8. 【参考】volatile 解决多线程内存不可见问题。对于一写多读，是可以解决变量同步问题， 但是如果多写，同样无法解决线程安全问题。如果是 count++操作，使用如下类实现： AtomicInteger count = new AtomicInteger(); count.addAndGet(1); 如果是 JDK8，推 荐使用 LongAdder 对象性能更好。

9. 【参考】 HashMap 在容量不够进行 resize 时由于高并发可能出现死链，导致 CPU 飙升，在 开发过程中可以使用其它数据结构或加锁来规避此风险。

10. 【参考】ThreadLocal 无法解决共享对象的更新问题，ThreadLocal 对象建议使用 static 修饰。这个变量是针对一个线程内所有操作共有的，所以设置为静态变量，所有此类实例共享 此静态变量 ，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只 要是这个线程内定义的)都可以操控这个变量。

 

IV  控制语句

1. 【推荐】除常用方法（如 getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复 杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。

2. 【推荐】循环体中的语句要考量性能，以下操作尽量移至循环体外处理，如定义对象、变量、 获取数据库连接，进行不必要的 try-catch 操作（这个 try-catch 是否可以移至循环体外）。

V  其它

1. 【强制】注意 Math.random() 这个方法返回是 double 类型，注意取值的范围 0≤x<1（能够 取到零值，注意除零异常），如果想获取整数类型的随机数，不要将 x 放大 10 的若干倍然后 取整，直接使用 Random 对象的 nextInt 或者 nextLong 方法。

2. 【强制】获取当前毫秒数 System.currentTimeMillis(); 而不是 new Date().getTime(); 说明：如果想获取更加精确的纳秒级时间值，使用 System.nanoTime()的方式。在 JDK8 中， 针对统计时间等场景，推荐使用 Instant 类。

3. 【推荐】任何数据结构的构造或初始化，都应指定大小，避免数据结构无限增长吃光内存。

 

(四) 异常处理

1. 【强制】Java 类库中定义的一类 RuntimeException 可以通过预先检查进行规避，而不应该 通过 catch 来处理，比如：IndexOutOfBoundsException，NullPointerException 等等。

说明：无法通过预检查的异常除外，如在解析一个外部传来的字符串形式数字时，通过 catch NumberFormatException 来实现。

正例：if (obj != null) {...}

反例：try { obj.method() } catch (NullPointerException e) {...}

2. 【强制】异常不要用来做流程控制，条件控制，因为异常的处理效率比条件分支低。

3. 【强制】对大段代码进行 try-catch，这是不负责任的表现。catch 时请分清稳定代码和非稳 定代码，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的 catch 尽可能进行区分 异常类型，再做对应的异常处理。

4. 【强制】捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请 将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的 内容。

5. 【强制】有 try 块放到了事务代码中，catch 异常后，如果需要回滚事务，一定要注意手动回 滚事务。

6. 【强制】finally 块必须对资源对象、流对象进行关闭，有异常也要做 try-catch。

 说明：如果 JDK7 及以上，可以使用 try-with-resources 方式。

7. 【强制】不能在 finally 块中使用 return，finally 块中的 return 返回后方法结束执行，不 会再执行 try 块中的 return 语句。

8. 【推荐】定义时区分 unchecked / checked 异常，避免直接抛出 new RuntimeException()， 更不允许抛出 Exception 或者 Throwable，应使用有业务含义的自定义异常。推荐业界已定义 过的自定义异常，如：DAOException / ServiceException 等。

 

(五) 日志规约

1. 【强制】应用中不可直接使用日志系统（Log4j、Logback）中的 API，而应依赖使用日志框架 SLF4J 中的 API，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

private static final Logger logger = LoggerFactory.getLogger(Abc.class);

2. 【强制】日志文件推荐至少保存 15 天，因为有些异常具备以“周”为频次发生的特点。

3. 【强制】异常信息应该包括两类信息：案发现场信息和异常堆栈信息。如果不处理，那么通过 关键字 throws 往上抛出。

正例：logger.error(各类参数或者对象 toString + "_" + e.getMessage(), e);

4. 【推荐】谨慎地记录日志。生产环境禁止输出 debug 日志；有选择地输出 info 日志；如果使 用 warn 来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘 撑爆，并记得及时删除这些观察日志。

5. 【参考】可以使用 warn 日志级别来记录用户输入参数错误的情况，避免用户投诉时，无所适 从。注意日志输出的级别，error 级别只记录系统逻辑出错、异常等重要的错误信息。

 

二、MySQL 数据库

(一) 建表规约

1. 【强制】表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只 出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。

2. 【强制】表名不使用复数名词。

3. 【强制】禁用保留字，如 desc、range、match、delayed 等，请参考 MySQL 官方保留字。

4. 【强制】主键索引名为 pk_字段名；唯一索引名为 uk_字段名；普通索引名则为 idx_字段名。

5. 【强制】小数类型为 decimal，禁止使用 float 和 double。

说明：float 和 double 在存储的时候，存在精度损失的问题，很可能在值的比较时，得到不 正确的结果。如果存储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数分开存储。

6. 【强制】如果存储的字符串长度几乎相等，使用 char 定长字符串类型。

7. 【强制】varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长 度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索 引效率。

8. 【强制】表必备三字段：id, create_time, update_time。

说明：其中 id 必为主键，类型为 unsigned bigint、单表时自增、步长为 1。create_time的类型为 datetime 类型。

9. 【推荐】表的命名最好是“业务名称_表的作用”。

正例：tiger_task / tiger_reader / sys_user

10. 【推荐】字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循：

1）不是频繁修改的字段。

2）不是 varchar 超长字段，更不能是 text 字段。

 正例：商品类目名称使用频率高，字段长度短，名称基本一成不变，可在相关联的表中冗余存 储类目名称，避免关联查询。

11. 【推荐】单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

 说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

12. 【参考】合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提升检 索速度。

正例：如下表，其中无符号值可以避免误存负数，且扩大了表示范围。

 

 

对象	年龄区间	类型	表示范围
人	150 岁之内	unsigned tinyint	无符号值：0 到 255
龟	数百岁	unsigned smallint	无符号值：0 到 65535
恐龙化石	数千万年	unsigned int	无符号值：0 到约 42.9 亿
太阳	约 50 亿年	unsigned bigint	无符号值：0 到约 10 的 19 次方

 

 

 

(二) 索引规约

1. 【强制】业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。

 说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明 显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必 然有脏数据产生。

2. 【强制】 超过三个表禁止 join。需要 join 的字段，数据类型必须绝对一致；多表关联查询 时，保证被关联的字段需要有索引。

说明：即使双表 join 也要注意表索引、SQL 性能。

3.【强制】在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据 实际文本区分度决定索引长度即可。

 说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分度会高达 90%以上，可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度 来确定。

 

4.【推荐】如果有 order by 的场景，请注意利用索引的有序性。order by 最后的字段是组合 索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。

正例：where a=? and b=? order by c; 索引：a_b_c

反例：索引中有范围查找，那么索引有序性无法利用，如：WHERE a>10 ORDER BY b; 索引 a_b 无法排序。

5. 【推荐】利用延迟关联或者子查询优化超多分页场景。

说明：MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后返回放弃前 offset 行，返回 N 行，那当 offset 特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过 特定阈值的页数进行 SQL 改写。

正例：先快速定位需要获取的 id 段，然后再关联：

SELECT a.* FROM 表 1 a, (select id from 表 1 where 条件 LIMIT 100000,20 ) b where a.id=b.id

6. 【推荐】建组合索引的时候，区分度最高的在最左边。

正例：如果 where a=? and b=? ，a 列的几乎接近于唯一值，那么只需要单建 idx_a 索引即 可。

说明：存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置。如：where a>? and b=? 那么即使 a 的区分度更高，也必须把 b 放在索引的最前列。

 

(三) SQL 语句

1. 【强制】不要使用 count(列名)或 count(常量)来替代 count(*)，count(*)是 SQL92 定义的 标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。

说明：count(*)会统计值为 NULL 的行，而 count(列名)不会统计此列为 NULL 值的行。

2. 【强制】count(distinct col) 计算该列除 NULL 之外的不重复行数，注意 count(distinct col1, col2) 如果其中一列全为 NULL，那么即使另一列有不同的值，也返回为 0。

3. 【强制】当某一列的值全是 NULL 时，count(col)的返回结果为 0，但 sum(col)的返回结果为 NULL，因此使用 sum()时需注意 NPE 问题。

4. 【强制】使用 ISNULL()来判断是否为 NULL 值。注意：NULL 与任何值的直接比较都为 NULL。

说明：

1） NULL<>NULL 的返回结果是 NULL，而不是 false。

2） NULL=NULL 的返回结果是 NULL，而不是 true。

3） NULL<>1 的返回结果是 NULL，而不是 true。

5. 【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。

6. 【推荐】in 操作能避免则避免，若实在避免不了，需要仔细评估 in 后边的集合元素数量，控 制在 1000 个之内。

 

三、工程结构

(一) 应用分层

1. 【推荐】图中默认上层依赖于下层，箭头关系表示可直接依赖，如：开放接口层可以依赖于Web 层，也可以直接依赖于 Service 层，依此类推：

·      开放接口层：可直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 http 接口；进行 网关安全控制、流量控制等。

 

·      终端显示层：各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染，JSP 渲染，移动端展示等。

·      Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。

·      Service 层：相对具体的业务逻辑服务层。

·      Manager 层：通用业务处理层，它有如下特征：

 1） 对第三方平台封装的层，预处理返回结果及转化异常信息；

 2） 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理；

 3） 与 DAO 层交互，对多个 DAO 的组合复用。

·      DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 进行数据交互。

·      外部接口或第三方平台：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。

 

2. 【参考】 （分层异常处理规约）在 DAO 层，产生的异常类型有很多，无法用细粒度的异常进 行 catch，使用 catch(Exception e)方式，并 throw new DAOException(e)，不需要打印 日志，因为日志在 Manager/Service 层一定需要捕获并打到日志文件中去，如果同台服务器 再打日志，浪费性能和存储。在 Service 层出现异常时，必须记录出错日志到磁盘，尽可能带 上参数信息，相当于保护案发现场。如果 Manager 层与 Service 同机部署，日志方式与 DAO 层处理一致，如果是单独部署，则采用与 Service 一致的处理方式。Web 层绝不应该继续往上 抛异常，因为已经处于顶层，无继续处理异常的方式，如果意识到这个异常将导致页面无法正常 渲染，那么就应该直接跳转到友好错误页面，加上友好的错误提示信息。开放接口层要将异常 处理成错误码和错误信息方式返回。

3. 【参考】分层领域模型规约：

DO（Data Object）：与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。

DTO（Data Transfer Object）：数据传输对象，Service 和 Manager 向外传输的对象。

BO（Business Object）：业务对象。可以由 Service 层输出的封装业务逻辑的对象。

Query：数据查询对象，各层接收上层的查询请求。注：超过 2 个参数的查询封装，禁止 使用 Map 类来传输。

VO（View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。

4. 【参考】API层规约：

建议采用Restful 风格，通过URL用来定位资源，跟要进行的操作区分开，这就意味着URL不该有任何动词。实际上，在HTTP请求中，我们不只有GET 和 POST 可用，在 REST 架构中，有以下几个重要的请求方法：GET，POST，PUT，DELETE。

 

【GET】     用于对某一(些)资源的‘获取’

【POST】    用于对某一(些)资源进行‘创建’

【DELETE】  用于对某一(些)资源进行‘删除’

【PUT】     用于对某一(些)资源进行‘更新’