[size=medium] 一个交易系统每天数据量都很大,日积月累历史表中就会有很多的数据,如果在交易过程中后台查询报表以及查看交易情况,会严重干扰到交易的进行,导致交易进行缓慢。
这个时候想到了由于数据库采用了实时备份策略,准备后台数据库查询的时候才用备用数据库查询数据,前台只用来处理交易。
沿着这个思路添加了备用库的数据源,在查看代码的过程中,将查询和非查询放到两个不同的DAO中,查询的指向备库数据源,非查询的指向主库数据源。但是有些地方使用的公用的方法,改动量太大了,于是只将需要的地方抽出来重新建一个DAO。
在改数据源的过程中才发现一个精良的系统设计是如此的重要,因为有一个模块我就改了下数据源的指向就OK了。
此次我的心得:
1、一个菜单下的尽量放到同一个控制层文件中,采用通用的配置,只调用本部分接口中的方法和整个系统的公用方法。
2、大量用到的方法抽取为公用方法,JSP页面中不要出现JAVA代码,否则要改动的时候需要改动的地方太多
3、大量数据的地方应该在设计阶段就考虑到如何处理。
4、模块化设计很重要啊,各模块调用尽量通过公用接口[/size]
这个时候想到了由于数据库采用了实时备份策略,准备后台数据库查询的时候才用备用数据库查询数据,前台只用来处理交易。
沿着这个思路添加了备用库的数据源,在查看代码的过程中,将查询和非查询放到两个不同的DAO中,查询的指向备库数据源,非查询的指向主库数据源。但是有些地方使用的公用的方法,改动量太大了,于是只将需要的地方抽出来重新建一个DAO。
在改数据源的过程中才发现一个精良的系统设计是如此的重要,因为有一个模块我就改了下数据源的指向就OK了。
此次我的心得:
1、一个菜单下的尽量放到同一个控制层文件中,采用通用的配置,只调用本部分接口中的方法和整个系统的公用方法。
2、大量用到的方法抽取为公用方法,JSP页面中不要出现JAVA代码,否则要改动的时候需要改动的地方太多
3、大量数据的地方应该在设计阶段就考虑到如何处理。
4、模块化设计很重要啊,各模块调用尽量通过公用接口[/size]