web后端实际开发中的经验总结

1.关于请求地址，每个Controller上有一个一级路径，然后每个方法上有一个二级路径。这样根据请求路径能迅速找出所在的Controller。

2.系统分层时每层的接口名用I(interface)开头，这样在实现类里就可以大摇大摆的使用原名，而不用修改默认value了。调用时直接调用原名。

3.关于UUID，可以使用注解生成，也可以在SQL执行之前，调用UUID的工具方法得到结果加入语句里。

4.项目提交时不能全部提交，因为可能会不小心更改了哪而把错误提交出去，所以主动改了哪提交哪。

5.开发时通常是增量开发，因为要改原来的架构，要动的东西太多。

6.增删改操作要放在事务中，使用transactional注解。写在service层，对于一个操作，三层只能使用一个事务，要不然会不执行。

7.SQL语句的关键字大写，这样更明显。

8.系统中有些逻辑不是在得到请求时执行的，需要在服务器不定期或者特定条件下自动执行，按自动任务来写。

9.在sql语句中，where后面的条件，传入的参数要和字段一一对应。

10.在sql查询中，如果返回一组值，而没有对应的实体类进行封装，可用类似的实体类，甚至只要属性的类型一致就行了。

11.项目中有错也能执行，严重错误项目启动不了。

12.SVN回滚到之前版本时，修改后不可提交，解决方法，全部复制修改后的版本，更新到最新版后粘贴。在最新版本提交。

13.项目问题修复方法：看数据，查日志，找方法，修改，测试，打补丁

14.后端的日志是不断生成和不断删除的，删除在自动任务里。

15.下层的异常一般往上抛，在上层解决，如果不跑，要在下层解决。

16.E-R图，实体关系模型图，设计先后顺序，跟据业务来决定E-R关系图，跟据E-R图来设计实体类和数据库表

17.数据库设计，每张表都有一个对应的实体，并且都有一个ID字段，当表之间时一对多和关系时，在多的那张表上要有一个少的表的ID的字段作为外键；多对多时，设计一个中间表，中间表有两各表的ID作为字段，体现多对多关系。

18在使用js时，如果出现该方法没有定义的报错，一般都是之前的方法出现了错误，或者该方法出现错误。

19.返回json的字符串，是一个JsonResult对象，里面包含了返回的status,msg,data 数据。

20同一个业务可以用不同的方法来实现，比如登陆，在业务层，判断返回user对象是不是空之后，可以通过抛异常的方式，也可以通过返回result对象的方式，把结果传给上一层。