我相信大部分程序员在用Java开发的项目中只用到了一种模式:MVC,将项目分成Controller,Service,DAO三层。无论多复杂的业务逻辑都塞进Service层的方法,其结果是造成Service层的方法臃肿无比,里面充满了各种if、switch逻辑判断的分支。时间一长,连开发者自己都忘了在方法里做了什么事。当业务逻辑发生变化时,动手改这块的代码成了一件十分困难,极易出错的事。
不幸的很,业务逻辑是整个项目中变化最频繁的部分,因此我强烈建议将Service层再拆分,举个我在实际项目中遇到的电信产品销售的例子:
不幸的很,业务逻辑是整个项目中变化最频繁的部分,因此我强烈建议将Service层再拆分,举个我在实际项目中遇到的电信产品销售的例子:
电信产品有宽带、号码、话费、流量等很多种,很显然,销售每种产品的业务逻辑是不一样的,比如销售宽带产品时需记录客户的家庭地址、预约上门安装时间;销售话费只需记录客户充值的手机号码等等。且业务逻辑经常会发生变化(经常进行促销活动),这种情况非常适合用策略模式来设计,我就是用策略模式来处理这类问题的。请看图:
ProductService是一个抽象类&