code-behind - 不可维护的代码背后的非技术性

Question

您如何向非技术人员解释为什么在 onclick 事件背后编写代码(业务逻辑)是一种不好的做法并导致无法维护的代码？

编辑:
我必须向管理层解释为什么需要进行一些重构，以及为什么有些代码没有通过代码审查。对于一些管理人员来说，这仅意味着更多的资金。我想出这个例子是因为在讨论的某个时候有人说:..把代码放在按钮后面，忘记所有模型- View - Controller 的炒作，你会更快地完成你的任务。

Answer 1

这就是我要解释的方式:

编写 onlclick 事件背后的代码和编写分层或分层的应用程序之间的区别，就像 之间的区别。中世纪小镇和一个 现代都市 .

在 中世纪小镇 ，人人耕田，人人缝衣，盖房子，尽其所能教育 child ，没有人是真正专门做好某项任务的，他们必须完成生存所必需的所有任务。
这就是在 onclick 事件背后编写代码的样子，代码必须做所有事情，处理 UI 交互，进行业务验证，处理数据库访问，并且这对每个事件重复。

在 现代都市有更大规模地从事农业并专门从事农业的农民，有因为经验丰富和特化而可以为每个人缝制更好衣服的裁缝，有 build 者，有在学校教 child 的老师，可以做得更好因为他们有更多的时间去做。这就是编写分层应用程序的样子，UI 层只负责处理用户请求和更新用户界面，因此更容易更改替换或扩展，没有额外的代码负担，业务层负责业务逻辑并且所有的逻辑都是集中的、可重用的，业务逻辑代码更简洁干净，数据访问层处理数据库交互，专门做可能与不止一种类型的数据库交互。

在 onclick 事件背后编写代码是一种基本的编程风格，它不是最有效的风格，从长远来看也不会产生最好的结果，尽管结果通常是可以接受的(应用程序可以工作)，但它可以正常工作通过使用采用良好编码实践的适当分层设计，更好、更易于维护和扩展并更加一致(关于 ui、交互、错误报告、工作流等)。