• 2014-05-16

    服务端软件设计(一)

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/271628797.html

    做服务端软件,几乎无可避免地会遇到集成。那些年受到SOA“熏陶”,对于很多团队来说,标准的做法似乎是这样的:从另外一个地方弄来一个WSDL,然后,用它生成代码。

    是时候编写自己的代码了,你的团队会怎么做?既然有了生成代码,它基本上也算是很好地反映了我们的业务需求,那就直接用这些类作为我们的领域对象,一切轻轻松松。

    下面是我的一个真实经历。

    还有最后一天,我们的项目就要发布了。这时客户一个技术负责人跑了过来,“有一个接口我们不能用了”,那是我们最重要的一个接口,少了它,整个应用几乎就不可用。不幸中的万幸是,有一个功能等价接口可以用。不过,这个新接口是一个完全不同的协议,一个全新的WSDL。

    先别抱怨为什么这么关键的问题在最后一天才发现。我们先想想这个变动会对系统造成怎样的影响。

    如果我之前的开发是依赖于这些生成代码,将其作为我的领域对象,作为一个核心功能,这就意味着我所有的代码几乎都要依赖于这些类。替换它几乎要把所有代码修改一遍。可明天我们就要上线了!

    你明白我的意思了,直接依赖于这些生成代码,几乎就宣判了项目的死缓。

    间接层,是解决许多所有计算机问题的利器。在这里也不例外。我们对于这种问题的解决方案是,编写自己的领域对象,即便它看上去生成对象一模一样。事实上,在这个问题上,阻碍许多人编写自己领域对象的原因多半就是两个类会一模一样。

    在软件设计中,一个重要的原则就是向着稳定的方向依赖。生成的代码是别人的东西,别人的东西稳定性是什么样的,谁知道呢!即便是JDK,大部分类也不是像我们想的那样稳定,比如日期,随着大家对于这些类日益深入,一些问题就会暴露出来。如果是自己团队编写的代码,至少有一个非常重要的优点,我们拥有控制权,我们可以根据业务发展需要自行修改。依赖别人永远不如依赖自己靠谱。

    回到我的经历上。实际上,我那天真正做的修改就是重新写了一下从生成协议代码到自己领域对象适配部分的代码,因为生成代码与其它部分代码没有任何关系。

    分享到:

    历史上的今天:

    争论TDD 2010-05-16
    引用地址: