如何解决庞大臃肿的service层

Question

业务代码写的太多了导致过于臃肿，请问怎么解决？或者使用哪种设计模式

Answer 1

哪种设计模式……恐怕搞不定，23种设计模块估计你需要用到近一半 如果 Service 层太臃肿，可以考虑层次细分，甚至可以把平面分层改为树型分层(分子系统或模块)。 如果要减少代码，可以通过重构和设计模式把重复代码去掉，但是分层和模块本身会增加代码量。所以最终结果可能并不会减少代码量，但是层次结构会更清晰。 以阅读为目的进行重构，再通过测试和分析对部分地方进行性能优化——说起来简单，做起来还是很累人的

Answer 2

既然觉得臃肿，那么就要对应的'瘦身'啊 不要把所有的API都写在service层，可以根据代码逻辑划分一些到dao层或者util中 尝试着一些面向对象，将某一类的代码写到某一类的service中，这样某一类的service应该不会很庞大 增加覆用，少些重复的代码，可以通过继承和封装等手段，Don't repeat youself

Answer 3

1、将臃肿的service类拆分成更细的service类2、尽量不要写超复杂的方法：比如方法F要做A,B,C三件事，那就将A,B,C三件事都抽象出来单独写一个方法，由F方法调用A,B,C三个方法，这样F方法就瘦身了3、service类尽量只做逻辑处理，对于功能性的方法（比如http请求，比如空值判断）将其封装到公共方法中，例如util类。4、尽量将通用方法抽象出来放到基类BaseService中，比如基础的search，create，update，delete等。 事实上，像eclipse和idea这些现代IDE都有优化提示的功能，就是那惹人生厌的黄色警告。如果你将黄色警告都解决了的话，上面的问题起码能避免一半

Answer 4

请遵守SOLID原则写代码

Answer 5

如果单个项目过于庞大，拆分成多个项目是必然的，但要分几个阶段： 界面展示和业务逻辑分离。将项目拆分成 Web 应用和服务，Web 应用调用服务获得要展示的动态内容。 如果上面拆分后服务项目仍然过于庞大，就需要按业务领域拆分。比如用户服务、产品服务、社交服务、工单流等等，分开来。这一步要十分谨慎。