今天下午和新来的同事聊起技术研究来了,大家都有一个共同点,就是从项目的需要出发,解决最根本,最本质的问题是我们技术研究的目标。
期间,我们谈到项目中的异常处理框架的问题;谈到事务处理的问题;谈到引入AOP解决很多需要改代码才能加功能的问题;最后谈到领域建模的问题。
我觉得通过这样的交流是比较有好处的,自己也得到了提高,至少对事务在哪里处理这一点上。我认识到之前我的程序的设计不正确,应该把事务放在Service方,而不应该方在DAO那边。DAO的方法应该是尽可能的简单,而业务逻辑的方法会比较负责,业务逻辑的方法可能会调用多个DAO完成一个业务操作,并且对于用户来说,一个业务方法才是一个原子操作。所以,在DAO方法里面加上事务只能保证你这个DAO操作是原子的,但是不能保证Service方法是原子的。
将事务切换到Service方法中,需要做一些操作。典型的有Spring AOP,当然,也可以采用filter,也可以采用ASPECTJ,各种方法都能够达到自己的目标:)
剩下的是我们如何去权衡了。
另外,关于领域建模的问题,我还是不得不说,我们的系统建立领域模型是有必要的。代码量已经超过600KLOC了,不提炼领域模型,这个系统的业务可重用性基本就为0。
有很多可以做的东西,希望技术研究的方向能够朝这些方面发展。
期间,我们谈到项目中的异常处理框架的问题;谈到事务处理的问题;谈到引入AOP解决很多需要改代码才能加功能的问题;最后谈到领域建模的问题。
我觉得通过这样的交流是比较有好处的,自己也得到了提高,至少对事务在哪里处理这一点上。我认识到之前我的程序的设计不正确,应该把事务放在Service方,而不应该方在DAO那边。DAO的方法应该是尽可能的简单,而业务逻辑的方法会比较负责,业务逻辑的方法可能会调用多个DAO完成一个业务操作,并且对于用户来说,一个业务方法才是一个原子操作。所以,在DAO方法里面加上事务只能保证你这个DAO操作是原子的,但是不能保证Service方法是原子的。
将事务切换到Service方法中,需要做一些操作。典型的有Spring AOP,当然,也可以采用filter,也可以采用ASPECTJ,各种方法都能够达到自己的目标:)
剩下的是我们如何去权衡了。
另外,关于领域建模的问题,我还是不得不说,我们的系统建立领域模型是有必要的。代码量已经超过600KLOC了,不提炼领域模型,这个系统的业务可重用性基本就为0。
有很多可以做的东西,希望技术研究的方向能够朝这些方面发展。