您如何向非技术人员解释为什么在onclick事件背后编写代码(业务逻辑)是一种不好的做法并导致无法维护的代码？
编辑:我必须解释管理为什么需要一些重构,以及为什么有些代码没有通过代码审查.对管理层中的一些人来说,这意味着更多的资金.我想出了这个例子,因为在讨论的某个时刻有人说:..输入按钮背后的代码并忘记所有模型 - 视图 - 控制器炒作,你将更快地完成你的任务.
Pop*_*lin 19
这就是我解释它的方式:
在onlclick事件后面编写代码和编写分层或分层的应用程序之间的区别就像中世纪城镇和现代城市之间的区别.
在一个中世纪小镇,每个人都在耕地,每个人都缝制衣服,建造自己的房子并尽最大努力教育他的孩子,没有人真正专业地完成任务,他们必须完成生存所需的所有任务.这就是在onclick事件背后编写代码的代码,代码必须做所有事情,处理UI交互,进行业务验证,处理数据库访问,并为每个事件重复.
在一个现代化的城市,有农民更大规模地从事农业并专注于农业,有裁缝可以为每个人缝制更好的衣服,因为有更多的经验和专业,有建设者,有教师在学校教孩子们可以做得更好,因为他们有更多的时间去做.这就是编写分层应用程序的样子,UI层负责处理用户请求并仅更新用户界面,因此更容易更改替换或扩展,因为没有额外的代码负担,业务层负责业务逻辑并且所有逻辑都是集中的,可重用的,业务逻辑代码更紧凑和干净,数据访问层处理数据库交互并专门做它可能与多种类型的数据库交互.
在onclick事件后面编写代码是一种基本的编程风格,它不是最有效的风格,并且从长远来看不会产生最好的结果,虽然结果通常可以接受(应用程序工作),它可以工作分配更好,更容易维护和扩展,并通过使用采用良好编码实践的适当分层设计更加一致(关于ui,交互,错误报告,工作流等).
| 归档时间： |
|
| 查看次数： |
856 次 |
| 最近记录： |