开发规范学习心得

  

开发规范学习心得

 

单超

2007.8.15日

1。文件名大小写的规定，JSP文件必须全部小写。

原因：开发时用的是windows的平台，windows并不区分文件名的大小写。而真正实施的时候使用的是UNIX平台，他完全区分大小写，所以如果开发时候不遵守这个规范，很可能就会在windows平台下把这个问题遗漏掉。

 

2。在update操作前，必须先把这条记录查出来再update

原因：这个涉及到Hibernate的缓存机制，不是很理解。

 

3。catch块中不允许写任何逻辑代码。

原因：正常的业务逻辑不应该依赖于异常的捕获。

 

4。原则上不允许启跨方法的长事务。

原因：长事务比较复杂。

长事务涉及的问题有这么几个：

第一、长事务的开启和关闭应该由哪个方法来做。

第二、长事务必须在一个线程上完成，否则没有意义。

解决方法：

第一、判断线程上是否有开启的事务，如果有，说明当前方法是事务内的一个子部分，不需要开启和关闭事务，如果没有，说明该方法是事务的发启者，必须开启和关闭事务。

第二、把事务绑定在当前线程之上，就解决了一个事务必须在一个线程上完成的问题。

 

5。事务必须尽量短小

说明：组织数据的操作应该放在事务的外面，事务应该只执行OP操作，保持尽量简短

原因：如果事务体写的比较大，就会出现以下三个问题

第一、占用回滚段资源

第二、事务执行期间锁表

第三、占用连接池的连接

 

6。事务的提交和回滚必须非常小心

原因：如果在事务内部使用了循环，判断，分支等结构，必须让每一个分支都走到提交或回滚的操作上。否则很容易产生既没提交也没回滚的脏连接。这样就会锁定很多的表。会造成十分严重的错误。

 

7。调用存储过程(这一块没太明白)

注意：调用存储过程这一块，不是使用hibernate写的，而是使用了JDBC。因为hibernate作为一个通用的ORM，不应该也不会去过多地关注各个数据库的特殊处理，而调用存储过程的操作各个数据库都是不一样的，所以hibernate对这方面的支持就十分微弱。

注意：存储过程中发生的错误是无法用java代码捕获的，所以所有调用存储过程的JAVA代码都会得到标识了存储过程执行成功或失败的返回值，我们必须根据这个值，手动地抛出一个异常。

 

8。防止重复提交

重复提交有以下三种情况：

第一、连续点按纽

第二、刷新页面

第三、后退(客户不会经常犯这样的错误)

解决办法有三个，分别针对以上三点

第一、javaScript控制，又细分为两种，一种是按钮置灰，一种是在页面加载时，在page_init()方法中，将表单里的值全部记录下来，然后在点业务按纽时，判断当前表单值是否与加载时的值一样。如果一样，不允许提交。

第二、所有业务逻辑的Action配置的ActionForward都必须重定向到查询页面，注意：一个是必须用重定向，而不是转发，再一个是必须重定向到别的，无法提交业务逻辑数据的页面。

第三、使用struts的令牌机制。(具体的不太明白)

 

9。保留查询条件(form=save)

原理：以当前的url为key，以查询form中的值集为value，在session中保存

 

10。保留分页信息(有个专门的标签，忘了是什么)

原理：以当前的url为key，以翻页按纽上的href为value，在session中保存

 

11。引入脚本文件或CSS文件时，必须使用base标签的属性而不能自己引入。

原因：如果自己引入，就必须写出CSS或JS的地址，那么就存在两种选择，一是写地址的绝对路径，二是写相对路径。这两种做法都存在以下问题。

第一：如果写绝对路径，就相当于把项目名硬编码进去。

第二：如果写的是相对路径，当页面发生迁移时，由于页面的URL显示的是Action的地址。那么就会出现相对路径的参照点不确定，那么相对路径也就没有意义了。

 

12。如果要在页面加载完毕后执行一段javaScript代码，必须将这段代码写在page_init()方法中，而不能在页面的底部写这些代码段。

原理：page_init()方法是在base的onload属性中设置了的，当页面完成加载时，就会自动调用page_init()方法。page_init()方法在JS文件中被定义成一个空的方法，需要我们重写这一方法。

 

13。按钮的functionId必须要写

原因：为了以后赋权的方便

原理：session中缓存了这该用户的权限，在页面加载时，自定义的button标签，会根据这个标签上的functionId属性，和session中的用户权限，自动判断这个用户有没有权限看到这个按纽。如果用户没权限，就根本不往页面上生成这个按纽的代码；如果有权限，才往页面上写这行代码。

 

14。所有的BS必须实现一个统一的接口。（不记得叫什么接口了）

原因：由于所有的BS都是一个类型的东西，所以理论上来说，他们属于面向对象世界中的一类对象，就应该有一个接口来统一他们。但是由于现在这个接口还是一个空的接口，所以还没什么用处。但是如果以后需要给所有的BS都加上一层功能，那么只需要在这个接口中改就可以了，现在这样做，只是为以后留出一个好的基础。

 

原理：JAVA中的接口分为两种类型，一种叫做功能接口，也就是定义了方法签名的接口。第二类是叫标志性接口，这种接口不定义任何方法，只是用来标识某个对象是属于哪一类的，比较典型的是JAVA的序列化接口。

 

15。在检查textarea和长输入框的内容长度时，必须使用getBytes方法获取长度，不能使用length属性获取长度。

原因：javaScript只检查字数，也就是把汉字也当成一个长度，但是汉字其实是两个比特的。

原理：这个getBytes()方法是通过css 的behavior绑定上去的。css behavior确实是个很牛B的东西。但是目前没兴趣搞明白。

 

16。UTF-8字符集是unicode的一个子集，是用12位表示一个汉字，也就是用1.5个B表示一个汉字的。

 

17。tab页的权限跟button一样。

 

18。使用session时必须小心。

原因：真正的原因不是因为session耗费资源，这些都可以通过session管理策略来实现性能的优化。真正的原因是在weblogic做系统集成的时候，会发生一个叫session漂移的情况。

session漂移:一台服务器把它内存中维护的某个session先序列化，然后传送给另一台服务器，接受到session的服务器，将这个session重建。经常发生的问题，

一、如果session中的对象没有实现序列化接口，那么就无法序列化，也就无法正确还原。

二、如果session中存放了大的集合，或大的javaBean。也就是说，存放了大的数据块，那么session漂移时，发生问题的可能性十分大。

 

目前为止，部门解决这个问题的方法，是要求客户使用硬件代理。硬件代理支持一种以客户为单位的负载均衡算法。也就是一个客户的请求始终发送给同一个服务器。

 

补充：代理转发请求的策略有这么几个。

第一类：weblogic自带集群软件的算法

1。容灾算法。一直只用一台服务器，直到这台服务期器挂掉，就用别的备用服务器。

2。轮询算法。将请求轮流发给各个服务器

3。负载均衡算法。测试服务器负担，把当前请求发给负载最轻的服务器。

第二类：硬件代理的一个比较好的算法

以用户为单位转发，一个用户的请求总是发给同一个服务器。这样就不会发生session漂移的问题了。