应用程序框架 DO
应用程序框架设计之前言
要做一个应用程序框架的念头Bigtall在几年前就有了，因为在工作中发觉很多方面非常的不顺手，几乎每一个环节都存在这样或者那样的问题：
- 公司不同项目组做的设计是完全不同的风格，而且设计做不细，导致项目计划越来越流于形式
- 各层代码凌乱，从后台的java或者c#到前台的html，天马行空，随心所欲
- 数据库结构和文档不匹配，要不是莫名其妙的多、少字段，要不就是些莫名其妙的名字
如果深入到设计方面，就会发现虽然做过很多的项目，但是几乎没有可以参考的成功案例，所有的设计哪怕是同类型项目，也几乎要重头开始；编码方面就更加麻烦了，我最深刻的印象就是从业以来我编制了无数的字符串处理函数，有c/c++版本的，有C#版本，有java版本的，还有delphi和早已忘记的vb，当然，更少不了时下流行的js了（这还是好的呢）。一旦到了项目规模较大的时候，我们甚至会在代码流程中迷路，不知道调用从哪里来，不知道逻辑要往哪里跳。
这么多的问题，是广大的处于CMM 1级的软件企业共同存在的问题，当然也会出现在那些CMM2345实际还是CMM1的软件企业中。加入管理手段（比如真正去实施CMM规范）可以解决大部分的问题，准确地说是可以解决几乎所有的管理问题并缓解大部分的技术问题，但是解决不了所有的问题。
以前bigtall在的公司曾经出现过这种论调“技术是不重要的，市场和管理才是最重要的”，最后公司走入了低谷，好不容易聚集的人才也散了。别人的教训就是自己的经验，bigtall后来进行深刻的反思，认为这里有一个“度”的问题，我们先看两个极端“只有市场和管理但是没有技术”“只有技术没有市场和管理”的后果，一个是“守不住”，一个是“推不了”。其实两者是相辅相成的，技术可以把市场的门槛推高，市场和管理可以让技术更顺利地发展。所以一个公司没有“最好”的技术，只有“最适合”的技术。一个公司的技术目标应该也只应该是“不断降低公司的成本”。
最明显的就是项目系统设计的重用问题，无论你是CMM多少级，如果没有一个统一的软件架构，重用就会打折扣甚至根本就无法重用。就像南方人北方人沟通要用普通话，今人和古人沟通就必须用相同的文字（顺便鄙视并可怜一下朝鲜、韩国和越南）一样，前后的项目要能够沟通交流，他们就需要一个相同的结构。所以“程序框架”就是公司项目之间的“普通话”，也是项目内部的“润滑剂”。
这里要明确一下“程序框架（Framework）”和“软件架构（Architecture）”之间的区别，简单地说，程序框架是一个可以实际应用的代码集合，而软件架构可以看作是一种抽象的设计。另外，两者的关注面也不一样，程序框架热衷于解决实际运行过程中的问题，甚至会提供工具包或者辅助模块（比如权限系统、日志系统等），而软件架构则集中精力在各个部分（模块、组件等）之间的关系。两者其实是关于同一个事情的不同层次的东西。
我们可以来看一下如果存在程序框架会让文章开头的几个问题解决多少：
- 如果有程序框架，因为项目的WBS几乎是一致的，所以上一个项目的项目计划可以直接拿过来使用，而且经过几个项目之后，这个项目计划的模板会越来越细，越来越实用。
- 设计过程中，除了需求之外，概要设计、详细设计的重用性会很高。
- 因为结构一致，代码混乱性会降低到可以接受的程度，而且可以重用上一个项目的大部分代码。而且逻辑清晰，使得代码相对较小，不容易在代码中迷失。因为代码逻辑简单有序，所以测试起来会很容易。
- 降低管理成本，除了项目计划之外，测试计划，QA计划等等都可以重用，如果用CMM规范，项目评审的速度和质量都会有提高。
要做一个应用程序框架并不是一件容易的事情，一是这方面发展很快，而且水平相对较高，如果没有独到的解决方案，可能自己的框架一出来就过时了。二是应用程序框架涉及的方面较多，考虑清楚并不是一件容易的事情。三则是开发一个应用程序框架需要耗费大量的时间，也就是意味着公司需要花费（你的工资×开发时间+其他）这么多的金钱。
对于小公司来说，除非有着清醒的认识，否则开发自己的应用程序框架可能是自寻死路。bigtall建议小公司如果.net开发，则直接用Petshop4的框架，如果java开发，则直接使用appfuse进行开发，如果想要一个新的语言，则直接用Ruby On Rails开发吧。对于php没有建议，不太熟。
现在如果要开发一个应用程序框架，至少需要满足如下的几个条件：
- 分层（废话）
- 易于测试
- 易于扩展，并跟现有的其他系统进行无缝整合。一般要具有AOP、IOC、DI能力。
- 易于部署
- 具有权限，用户管理能力
- 有组织架构、工作流、规则引擎支持
- 有页面流转，状态管理能力
- MOF或者MDA能力
- SOA能力
- 界面技术的抽象能力（如WebForm，HTML，Ajax，Xml，Rich Web等）
bigtall的应用程序框架设计系列文章准备从简单开始，一步一步记录并呈现给大家bigtall开发框架的整个过程。文章列表如下：
- 多层应用之间的数据传递： 分层和层间数据传递（上）、分层和层间数据传递（下）
多层架构已经成为了标准，但是数据在穿越各个层次的时候，它的形态有什么变化和规律呢？ - 界面层的分析和抽象
界面层承载了应用程序所有的可视部分，究竟里边还有多少我们需要关注但是却忽略了的事实？ - MOF/MDA的支持和程序的设计规范
如果人在根本上是不可靠的，那么就尽可能不用人去做。但是到达这一步，我们还需要告诉机器一些什么东西？ - 工具！我的工具！
bigtall设计的小工具 - 待续
应用程序框架设计之二：分层和层间数据传递（上）
还记得97年左右开始的胖客户机和瘦客户机之争吗？之后又是CS和BS之争，然后又是两层和多层之争...，十年之后的今天我们再回过头看这些争论，一切似乎看起来都那么理所应当：程序怎么能不分层啊？可是再想一下，原来我们用了整整十年的时间才达成了一个程序架构要多层的共识（效率多低啊）！
要分层，当然基本就是三层了，其实多层的基础也是三层：界面层、业务逻辑层、存储层。多层只不过在三层的基础上把每一层或多或少再拆分出一些来而已，总的来说没有什么大的变化。本系列文章中讨论都以三层为基本概念。
本文着重讨论的不是如何分层和层的定义，而是在分层情况下，讨论层与层之间的数据传递问题。现在的程序很少仔细地去分析层与层之间的数据传递问题，通常都是一个对象从界面生成开始一路穿过，直接保存到数据库（最显著的标志当然就是xxxID了）。这样的做法对程序伤害很大。
首先我们从一个简单的例子开始：应用程序的添加用户功能。界面很简单，如下：
添加用户 登录名
密码
添加用户
要为这个界面设计数据结构通常也很简单，class LoginInfo{ public String name; public String password; } 就好了，然后我们在form提交的时候new一个并且填充好LoginInfo结构，就save(loginInfo)到数据库里边了，最常的做法还会加入一个int loginInfoID字段。我们把这种类似LoginInfo可以直接存储到数据库中的数据结构命名为Persistence Object，简称PO。嗯，看起来从头到脚用一个数据结构并没有什么问题啊！
问题会来的，bigtall来改变一下需求，通常我们需要给用户密码输入两次，所以界面修改如下：
添加用户 登录名密码
重复输入
添加用户
这样，form提交到服务器的数据结构就应该是这样：class LoginInfo2{ public String name; public String password; public String password2; }，然后服务器做的第一件事情就是比较password和password2是否相等，然后new一个LoginInfo结构，把name和password填充到里边，然后保存到数据库。我们同时把LoginInfo结构修改成这样class LoginInfo{ public int loginInfoID; public String name; public String password; } 。
大家可以看到，随着需求的变化，原来的“PO直通车”演化成了两个结构，我们把LoginInfo2类似的界面层和其它层沟通的数据结构叫做View Object，简称VO。是不是这样就够了？当然不是，我们再来修改一下需求，给系统加入权限功能，所以这个添加用户实际上应该修改成这样：
添加用户 登录名密码
重复输入
管理员 部门经理 普通员工
添加用户
我们需要继续做一些改进（或者叫做“重构”吧），首先修改VO，同时我们把命名也规范一下：
class LoginInfoVO{public String name; public String password; public String password2; public String[] roles;}，
然后把以前的LoginInfo拆分成三个类：
class LoginInfoBO{public String name; public String password; public RoleInfo[] roles;}
class LoginInfoPO{public int loginInfoID; public String name; public String password;}
class RoleInfoPO{public int loginInfoID; public String role;}。
至此，我们顺利地引出了三个概念：View Object（VO）、Business Object（BO）、Persistence Object（PO）。他们分别是三层结构的显示层、业务逻辑层和存储层内部使用的数据结构，它们还有一个统称，叫做数据传输对象Data Object（DO）。我们也可以把VO，BO和PO看成是DO在不同阶段的不同表示形态。当一个DO从显示层开始穿越整个系统的时候，它的形态和结构就开始变化，从VO转变到BO，最终到PO，但是这个过程不一定是可逆的，这个过程如果反向，从PO->BO->VO，很可能就对应不同的对象了。比如当输入错误的时候，回馈页面可能就需要增加一个错误信息提示。虽然实际使用的时候，我们经常会忽略这种细微的差异性，实际上这个错误信息，只对显示层有意义。
DO的转换规律一般可以总结为如下的几个类型，实际变化则可以是各种类型的组合：
- 属性内容的减少
属性内容的增减在DO不同形态之间的转变时候经常会发生。比如上例中添加用户LoginInfo对象的VO转换到BO的时候，就需要丢弃“重复输入密码”的属性。有些VO对象甚至根本不需要转换成BO。在BO转换成PO的时候同样也会有属性内容减少的情况出现，比如“部门”这类树状层次结构对象，因为运行效率的因素，也许会需要BO中有“下级部门列表”，实际存储到数据库的时候，PO只需要一个“上级部门ID”就可以了。
- 对象内容的填充或者增加
属性内容同样会有可能增加，但是在系统处理DO转换的时候，属性增加可能就意味着需要进行额外的查询和填充，比如我们使用“用户名”和“密码”进行登录的时候，最终系统需要通过数据库查询得到并且存储“用户ID”，以此来保证用户的唯一性。又比如提交的数据存在校验错误，我们可能需要重新刷新该页面，并且增加新属性“ErrorMessage”，以便把它显示在界面上，提醒用户注意。
- 对象的拆分和组合
我们可以看上面最后一个“添加用户”的例子，一个LoginInfo的BO转化为PO的时候被拆分成了2个对象，一个存放基本的用户信息，一个存放对应的Role信息。通常对象拆分的时候，常常需要填充或者补足新对象的内容；而对象合并的时候，常常出现内容减少的情况。
- 对象或者属性类型的变化
出现对象属性类型的变化在VO到BO的转换中比较常见，比如把用户输入的生日转化为一个真正的DateTime类型。
- 属性名称的变化
属性名称在转换过程中会有变化，一般这种情况应该尽可能不要出现，但是在项目重构的时候出现的概率较大。
除了DO不同形态之间的转换规律之外，不同形态内部还有不同的工作要做：
- 校验
“不要相信任何用户的输入”，这是设计程序跟用户进行交互操作时候永远需要遵守的一个原则。也就是所有的外部输入都需要进行正确性的校验。校验器是分为两个层次，一个是属性层次的校验，比如“年龄”只能0到150之间有效。另外一个是对象层次的校验，或者说跨属性层次的校验，比如“年份输入闰年的时候，2月可以有29日”等。
校验并不是一个单纯的问题，几乎所有的业务逻辑校验基本都需要一次完整的贯穿所有层次的调用。代价颇大。这个也是为什么我们在显示层做很多事先校验，而一旦进入业务逻辑层的时候，校验就经常会被“事后校验”代替了，人们会使用抛出异常的方法来代替“事前检查”。
突然想起来有一句闲话要讲。这个分析过程其实在一年前就完成了，那个时候正好沸沸扬扬的SOA满天飞，当把这个DO形态分析完毕之后，回头看SOA发现它并不属于表现层，而是属于业务逻辑层，换句话说它使用的DO必须是BO而不是VO。而所谓的SOA也不过就是分布的业务逻辑层而已。
因为以下的部分要花费较多的时间查找，bigtall怕文章搁久馊了，也怕各位看官等得太久，就分两部分发吧。下篇我们着重分析现net平台和java平台的几个架构在DO形态上的对比，还要谈一个实用的问题，是不是需要对象ID的问题。