从用户界面代码中分离业务逻辑是老一辈 VB 程序员教给我们的重要一课。Kathleen Dollard 实际上主张业务逻辑应该从任何技术中分离出来,以避免当新技术到来之时重写所有代码。并且,根据 Kathleen Dollard 的说法,代码就是技术,那么业务知识必须独立存在:
把业务逻辑和任何技术结合在一起注定让我们在获得新技术时要从基础部分重写代码——代码就是技术。
…你不能把代码和业务逻辑结合在一起。
任何闪亮漂亮的小工具和语言都会成为明天的老古董。
业务知识宁可保存在这些地方:“数据库结构、服务契约、测试定义、业务规则、工作流、业务对象编码、验证规则、授权准则、用户界面等等。”然而,人们可能会争辩到,无论我们选择了那个地方来隔离业务信息,它总是基于某项技术——这项技术总是会被改变的。虽然如此,在使用代码“作为表达意图的核心方式”和使用给定语法保存意图的表现之间总是存在一个关键的不同点的 :
你可以对这些声明识别、分类和确定形态。确实,任何声明的语法都是基于某个以此为目标的技术。…但是,任何元数据所含的价值都可以被转化为其他任何元数据语法。
Kathleen 主张的这种方法是,把代码生成作为从代码中提取和分离业务逻辑的一种手段。根据他的实践,她提出“即使最好的常规开发成果都会比平平常常的代码生成开发要差一些”。大部分专业团队使用敏捷方法也能按时成功交付有质量保证的软件,但在 Kathleen Dolard 的眼里,这样也可能会失败因为“整件事将随着新技术而重新开始。”
在生成的系统中需要着重强调的一点是,代码依旧扮演着一个决定性的角色。 无法定位错误就是 80 年代中 4GL(译者注:4th Generation Lanuage,第四代语言)灾难的一个原因。生成的代码可以避免这些易犯的错误,因为它实际上是“系统告诉你如何做”,这对于调试而言完全是具有决定性的。因此,Kathleen 把代码描述为“必要的邪恶”并认为确实应该这样对待代码生成。
她强调,这种方式对我们设想中的编程需要一个基本的转变,有效的领导力及适合工具将使代码生成完成的更好。Kathleen 论证到,如今“.NET 不是一个通过技术的变革来保护你的项目的接种疫苗”。它实际上加速了变革的步骤。然而,已经存在一些广泛使用代码生成的前提条件了。
在提及用于映射元数据或 XML 文本的实体框架的时候,Kathleen Dollard 说,他们“能让代码生成做令人吃惊的事情”以及具有“代替 XSLT 用于复杂生成功能”的潜力。Kathleen 希望代码生成这个领域在接下来的几年变得更有活力。她相信,基于“一种代码生成的组合方式,无声地为我们编写我们本来需要编写的代码”,可以让我们更接近正确的开发方式。
查看英文原文: Separating business logic from technology: Kathleen Dollard on a new view of code generation
评论