简单是王道《四、编程模型》

软件系统的开发有点像举办一场音乐会。首先是筹办（资源就位），了解希望来买票的观众是古典还是流行口味（需求），确定演奏什么曲目（SOW），演奏（开发）。为什么有点生硬地扯到音乐上来？因为本人想引出一个关于编程模型的比喻。原谅我继续生硬地把比方打下去。我们有了美妙的声音（Java），有了发出美妙声音的乐器（Eclipse），有了乐谱（系统设计），有了使用乐器的技巧（Java和Eclipse都很熟了），有了这些听得见摸得着的东西就会有好的音乐（软件产品）了吗？不，很关键的，还需要旋律和节奏。编程模型就像是音乐的旋律和节奏。

糟糕的是，在开发软件系统时，经常连谱（设计）也没有，只能即兴演绎，如果能把握旋律和节奏，也许能多对付一阵子：）

打了一堆比方，只是想表述一个观点：在软件系统的开发中，编程模型很重要，不是一般的重要。很多东西都是现成的，而编程模型需要创造。

在很多资料中，我们会看到Programming Model这个词。著名的MVC就是这样的Model，而迅速发展的Seam也提供这样的Model，许许多多的框架都提供各自Programming Model。这些Model为我们提供了编程的工作方式，准确地说，是限定了编程的工作方式。我们生产的各种小东西将要使用它们的模子，在它们提供的环境中工作，或者要使用它们规定的概念来交流和工作。看上去很遗憾，但这种做法是正确的。因为我们的业务系统将建立在一些非常有价值的软件资产基础之上。

在前面的文章中，我曾经提过这样的观点，企业信息系统的业务实现应该象一方净土，它应该只关注基于域模型的加加减减。是的，这个观点没有变。我们现在谈到了Programming Model，不是想打破简单是王道的原则，而是引入Programming Model的思想，把加加减减的工作更好地组织起来。我把这种组织叫做编程模型。有点晕，找不到好的词来表达这种想法。解释一下：编程模型有Programming Model的要素，又有些开发模型（以后会写篇文章，前两年领导过一家公司通过CMM认证的项目，有一些体会与大家分享）的要素。它面向基于域模型的加加减减，又包含了开发中的规则和约束。^_^，有点乱了乱了。

打个比方，用组件化来构建系统。编程模型会如何发生作用呢？可能有下面几点：
1、每个组件将作为一个独立的项目来管理和开发；
2、系统实现的结构目录会统一进行规划；
3、组件和接口将以统一的规范来建立；
4、组件的内部实现被规定了各种受控级别；
5、组件提供统一的扩展模式和机制；
6、组件服务将只被流程所使用；
7、客户端只能使用流程组件完成业务功能；
8、。。。

这里既约定了组件和接口这种具有Programming Model特征的要素，又包含系统实现的目录结构等超出Programming Model特征的要素。

Programming Model具有多样性，每一种框架都有各自的Model。通常这些Model是强制性的，例如，不写成servlet的那种样子，就不能在servlet引擎中工作。编程模型也是强制性的，但通常通过人为约定的方式进行。当然，我们也可以为自己的编程模型发明一个框架，来使各种约束自动化进行。有一些前提需要考虑。基于简单是王道的原则，基于域模型的加加减减是非常纯粹的POJO，目的是使业务逻辑可以生存在任何框架和环境中。这是完全做得到的。不能为了发明一个框架而使业务逻辑丧失移植性。

编程模型的价值在哪里呢？它使我们的系统结构有条理了，受控了，使我们的经验以固定的形式资产化了，等等等等，很多很多。有些时候，编程模型比我们使用的高级软件工具有价值的多。以前我曾经供职于一家全球领先的软件工具厂商，同样是深有感触。我会在后续的文章中一一道来。