最近将项目重构了一遍,以前没有用spring的时候性能还不错。虽然所有service都是临时new的,dao实现类用的工厂方法获取的,感觉速度挺不错。
这次重构了以后,就像前辈说的,患上了IOC的传染病,所有层次都用上了spring注入的方式,从dao注入datasource开始一直到action注入service,中间还有service注入了其它的bo(业务类)。发现这样的注入是可怕的,往往在开始一个action的时候需要一次性得到n个实例,cpu马上就上去了。卡在那里卡着,但是确实每个注入都不能删。是否在开始设计结构的时候就有问题?,因为我们的一个action里面有多个方法,每个方法用到的业务类都有可能不同,导致一个action里面(或者service)里面都有多达7,8个业务类注入,然后每个service还有多个bo注入,这样导致一次action调用,要注入n多个实例。
速度明显比以前慢了不少,只要有一个请求来了,cpu就上去了。100%,业务是无法简化了,而且也应该是默认的sington单例。
谁能?
这次重构了以后,就像前辈说的,患上了IOC的传染病,所有层次都用上了spring注入的方式,从dao注入datasource开始一直到action注入service,中间还有service注入了其它的bo(业务类)。发现这样的注入是可怕的,往往在开始一个action的时候需要一次性得到n个实例,cpu马上就上去了。卡在那里卡着,但是确实每个注入都不能删。是否在开始设计结构的时候就有问题?,因为我们的一个action里面有多个方法,每个方法用到的业务类都有可能不同,导致一个action里面(或者service)里面都有多达7,8个业务类注入,然后每个service还有多个bo注入,这样导致一次action调用,要注入n多个实例。
速度明显比以前慢了不少,只要有一个请求来了,cpu就上去了。100%,业务是无法简化了,而且也应该是默认的sington单例。
谁能?