关于业务分层
根据MVC分层思想，我们的项目都会分成3层，而业务层是在M里面的。
现在的项目都会把M分层两层即DAO层(持久层)和Service层(业务层)。
由于业务的发展,Service层里面的业务会越来越复杂,这个时候为了保持Service层方法的抽象层次一致性,一般我们都会写成堆成堆的private方法，举个例子。
createOrder()方法中保持了抽象的一致性(增加代码的可阅读性,方便维护),但是里面的私有方法createOrderInfo()里面里面又有一个私有方法。如果这种情况很多的话,那么这个类就会变成一个私有方法很多的类。这个时候我觉得应该在service和dao中再增加一层,该层的抽象层次在service和dao之间。这样子的话,我们就可以把一些业务封装在该层，增加代码的可读性和维护性至于扩展性我目前还没有想到哪个场景可以增加扩展性。
不知道你们对这个是怎么看的。
写回答
-
我说我不帅他们就打我，还说我虚伪1.个人认为，MVC里面，control，service，dao都属于控制层。前端界面作于view，数据库充当Model的角色
2.在service里面有很多private方法其实没有太大问题。如果需要可以增加manager这样的层次对某些privae方法进行封装。但是层次分的太多，在实际开发的时候就会觉得很繁琐，一个小功能就需要来几个层次间串。其实也是一种维护和开发成本。- 一般事务的界限会划分在service层的public方法，所以写private方法的时候要小心，不然嵌套在一起会出现一些问题。
2019-07-17 18:48:37赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
