当你提出，在页面调用逻辑时，不要在一个类中调用十几个方法，而且是将这个类中的方法封装一下，让页面就调用一到两次的时候，领导提出疑问，为什么要这么做，这么做有什么好处，要怎么回答才能让他明白呢?
并且要列出有哪些风险，如何避免时，要如何列出呢？
------解决思路----------------------
所以，要收拾其实没问题
问题在与你基于什么收拾，如果只是你觉着想代码好看点，我说在UI部分，这个没必要。核心逻辑部分可以弄好看点，毕竟能让以后滴人看得舒服也是理由，不过UI上没啥必要，UI跟客户跑滴，不是你逻辑跑滴
------解决思路----------------------
如果一个东西原本就“在你的心里”，那么你用不着死气白咧地“罗列出一堆风险”，你只要追逐的最自然的描述方式开始分析就好了。
比如说某人要在网页上“购买一个产品”的时候，系统首先需要确保此人确实已经登录了，此人有购买产品的权限，产品不在黑名单上，产品在指定的仓库确实有货，根据收货地址而计算运费并合计到产品价格中，使用代金券，准备礼品，扣费，更新此人的统计信息，更新厂商或者供应商的信息，记录日志......等等操作。
如果有人说这个操作涉及到8个数据库13个数据库表4个服务系统，那么“应该”还是“不应该”封装这个“购物”操作为一个对服务器请求的命令呢？
很显然，这个操作涉及多少数据库表、多少后台服务，后台的服务器（接入服务器、应用服务器、数据库服务器、文件服务器等等，以及各种后台业务服务接口）的部署分别在哪里，数据库系统买的是什么厂商的，这些都应该对前端隔离，后端随时可能调整。这就是原因，因为这些对我来说是真实的。
如果你心里没有具体的原因，非要别人帮你瞎编出原因来，那么你的领导就在那里等着戳穿你得“瞎编”呢。所以你才会语塞。
所以这种东西靠你自己动脑筋去想、去做调查研究。绝不能因为技术感觉时髦就去拼凑理由。