应用程序框架设计之前言
要做一个应用程序框架的念头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 Transfer Object（DTO）。我们也可以把VO，BO和PO看成是DTO在不同阶段的不同表示形态。当一个DTO从显示层开始穿越整个系统的时候，它的形态和结构就开始变化，从VO转变到BO，最终到PO，但是这个过程不一定是可逆的，这个过程如果反向，从PO->BO->VO，很可能就对应不同的对象了。比如当输入错误的时候，回馈页面可能就需要增加一个错误信息提示。虽然实际使用的时候，我们经常会忽略这种细微的差异性，实际上这个错误信息，只对显示层有意义。
DTO的转换规律一般可以总结为如下的几个类型，实际变化则可以是各种类型的组合：
- 属性内容的减少
属性内容的增减在DTO不同形态之间的转变时候经常会发生。比如上例中添加用户LoginInfo对象的VO转换到BO的时候，就需要丢弃“重复输入密码”的属性。有些VO对象甚至根本不需要转换成BO。在BO转换成PO的时候同样也会有属性内容减少的情况出现，比如“部门”这类树状层次结构对象，因为运行效率的因素，也许会需要BO中有“下级部门列表”，实际存储到数据库的时候，PO只需要一个“上级部门ID”就可以了。
- 对象内容的填充或者增加
属性内容同样会有可能增加，但是在系统处理DTO转换的时候，属性增加可能就意味着需要进行额外的查询和填充，比如我们使用“用户名”和“密码”进行登录的时候，最终系统需要通过数据库查询得到并且存储“用户ID”，以此来保证用户的唯一性。又比如提交的数据存在校验错误，我们可能需要重新刷新该页面，并且增加新属性“ErrorMessage”，以便把它显示在界面上，提醒用户注意。
- 对象的拆分和组合
我们可以看上面最后一个“添加用户”的例子，一个LoginInfo的BO转化为PO的时候被拆分成了2个对象，一个存放基本的用户信息，一个存放对应的Role信息。通常对象拆分的时候，常常需要填充或者补足新对象的内容；而对象合并的时候，常常出现内容减少的情况。
- 对象或者属性类型的变化
出现对象属性类型的变化在VO到BO的转换中比较常见，比如把用户输入的生日转化为一个真正的DateTime类型。
- 属性名称的变化
属性名称在转换过程中会有变化，一般这种情况应该尽可能不要出现，但是在项目重构的时候出现的概率较大。
除了DTO不同形态之间的转换规律之外，不同形态内部还有不同的工作要做：
- 校验
“不要相信任何用户的输入”，这是设计程序跟用户进行交互操作时候永远需要遵守的一个原则。也就是所有的外部输入都需要进行正确性的校验。校验器是分为两个层次，一个是属性层次的校验，比如“年龄”只能0到150之间有效。另外一个是对象层次的校验，或者说跨属性层次的校验，比如“年份输入闰年的时候，2月可以有29日”等。
校验并不是一个单纯的问题，几乎所有的业务逻辑校验基本都需要一次完整的贯穿所有层次的调用。代价颇大。这个也是为什么我们在显示层做很多事先校验，而一旦进入业务逻辑层的时候，校验就经常会被“事后校验”代替了，人们会使用抛出异常的方法来代替“事前检查”。
突然想起来有一句闲话要讲。这个分析过程其实在一年前就完成了，那个时候正好沸沸扬扬的SOA满天飞，当把这个DTO形态分析完毕之后，回头看SOA发现它并不属于表现层，而是属于业务逻辑层，换句话说它使用的DTO必须是BO而不是VO。而所谓的SOA也不过就是分布的业务逻辑层而已。
因为以下的部分要花费较多的时间查找，bigtall怕文章搁久馊了，也怕各位看官等得太久，就分两部分发吧。下篇我们着重分析现net平台和java平台的几个架构在DTO形态上的对比，还要谈一个实用的问题，是不是需要对象ID的问题。
应用程序框架设计之二：分层和层间数据传递（下）
看了上篇之后大家的留言，好多人觉得DTO分这么多形态，给这么多名词，可能在实际中没有用处。其实相比.net而言，java在架构上的功力要深厚许多，要谈架构如果避开java不谈的话，就会肤浅许多。这一点上net可能还要许多年才能赶上（如果不加倍努力，恐怕永远就落后于java了）。至于说VO、BO、PO没有人分那么仔细，恐怕只是大家自己没有意识到自己在使用吧。正好下篇要对流行的架构进行分析，bigtall就斗胆show一下分析结果了。
针对在DTO的形态转换问题，bigtall选择了几个流行的架构进行了分析，主要就是想要看看他们是怎么做的，这几个架构分别是Petshop 4.0, Struts, Tapestry, Spring MVC。
首先我们看Petshop4，项目中包含22个子项目，我们按照三层架构的层次分类对这些子项目归类：
显示层：WEB CacheDependencyFactory ICacheDependency TableCacheDependency
业务层：Model BLL IBLLStrategy IMessaging MessagingFactory MSMQMessaging OrderProcessor
存储层： DALFactory IDAL DBUtility OracleDAL SQLServerDAL
权限相关的独立部分：SQLProfileDAL ProfileDALFactory OracleProfileDAL IProfileDAL Membership Profile
大家注意业务层的Model，里边定义了项目中使用到的所有数据对象，典型的BO。因为asp.net的组件化设计思想，导致没有明确的VO概念（被分散在诸如textBox1.Text中了）。但是我们看WEB项目中的AddressForm自定义控件代码：
public partial class AddressForm : System.Web.UI.UserControl {
public AddressInfo Address {
get { ....
string firstName = WebUtility.InputText(txtFirstName.Text, 50);
......
return new AddressInfo(firstName, lastName, address1, address2, city, state, zip, country, phone, email);
}
set {
if(value != null) {
...
if(!string.IsNullOrEmpty(value.FirstName))
txtFirstName.Text = value.FirstName;
...
}
}
}}
分明就是一个典型的VO到BO之间相互映射的代码。同样我们看同一project下的CheckOut.aspx.cs也存在类似的转换代码：从WEB界面控件中提取数据，构建OrderInfo，最终传入SQLServerDAL或者OracleDAL的Order类中，大家可以看到如下的代码：
public void Insert(OrderInfo order) {...
orderParms[0].Value = order.UserId;
...
orderParms[19].Value = order.AuthorizationNumber.Value;
...
}
这个同样是一个典型的BO到PO的转换过程，只不过我们用类似Hashtable的结构代替了自定义的PO对象而已。
参考文献：Microsoft .NET Pet Shop 4 架构与技术分析
接下来我们来看Struts。所有的WEB提交数据被放置到所谓的ActionForm对象中，很多人为了方便，直接自定义了一个类似Hashtable的结构来做通用的ActionForm了。这个ActionForm就是我们所说的VO。然后ActionForm传递给Action进行处理，一般Action都会把ActionForm内容作一次校验，然后构建BO，传递到Service层进行处理，Service层进行处理之后，调用DAO对象存储。因为java程序基本都使用了hibernate或者ibatis等模块，所以BO到PO的转换被封装掉了。
这里很多人使用struts或者其他java框架的时候，经常在Action中添加了过多的业务逻辑代码，把原本属于界面层后端的Action做成了业务层的东西，然后图方便对Service层代码只是做一个简单的转发调用，类似boolean XXService(XXBO bo) { return dao.save(bo); }，实在是大错特错了。
说明：bigtall并不认同参考文献中认为的Action属于业务逻辑层。我认为业务逻辑层判断的一个标准是不加修改或者加一个简单的wrap，就可以暴露服务作为SOA。Action显然不满足这样的要求。退一步如果非要说Action属于业务逻辑层，那也只能是一个专门针对struts的Service封装接口，不合适包含大量的业务逻辑代码。
Struts返回数据到界面层的方法是通过把BO填入到一个Hashtable结构，由界面jsp直接使用其值，就跟asp用法一样。
参考文献：Struts，MVC 的一种开放源码实现
Tapestry框架是一个和asp.net采用了相似设计思想的组件化的web框架。一个web请求提交到服务器的时候，tapestry把请求中的内容填入到页面对应的BasePage派生类对象的属性中，这是一个自动的VO填充过程（类似asp.net中把用户输入的内容填充到对应的TextBox对象的Text属性中）。然后这个BasePage派生类对象把自己的属性最终填充成一个BO，传递到Service层，Service层调用DAO对象通过Hibernate或者ibatis存储到数据库中。
返回数据到界面层使用ognl表达式，基本原理类似把BO或者VO填入Hashtable结构，然后酌情用ognl表达式选取。比asp/jsp用法要利索一些，因为是组件化，所以很整齐。
参考文献：了解 Tapestry，第 1 部分，了解 Tapestry，第 2 部分
Spring作为No.1的AOP框架，灵活性和可扩展性是它最大的优点。在Spring MVC框架中，web请求通过参数HttpServletRequest（类似一个Hashtable结构）存放所有的用户请求数据，传递给Controller处理。如果Controller是从SimpleFormController派生而来，则可以在jsp中使用bind机制自动把提交数据填充到一个指定的对象中（也就是VO了），否则就要手工从HttpServletRequest中获取。在Controller中可以把数据传递给Service层处理了。Service层的处理和其它java框架相同。
返回数据到界面层可以使用很多种方法，看使用不同的ViewResolver而定，可以用jsp，也可以用freemarker脚本或者velocity脚本，也可以自己定义一种新型的界面层描述。
参考文献：一步一步开发Spring Framework MVC 应用程序
从以上简单几个架构的分析，我们可以明显看出VO/BO/PO的相互转换过程。但是都有一个特点，就是对VO转BO有明确的处理和包装，但是对BO转VO忽略掉了，直接使用暴露BO对象，使用ognl或者其他技术直接取值。asp.net的WebForm相对复杂一点，但是也同样避开了VO的问题，但是赋值放到了类代码里边，灵活性相对少了一些。而BO转PO的问题，都倾向于用类似ORM的模块来处理。
DTO形态之间的转换讲了一大半，但是一个很实际的问题需要我们来面对，就是数据库ID的暴露问题。根据我们的理论，ID实际是属于PO的东西（以下简称POID），其实VO和BO中并不需要这个POID，另外就是暴露这个POID之后会存在很多的隐患，一旦程序检查不严格，很容易被人假造一个请求去修改不应该的数据。但是我们真的可以抛弃POID不用吗？bigtall同样用一个例子来说明。
bigtall依旧使用上篇的LoginInfo的例子，不过这次的场景是查询特定的LoginInfo并修改之。这个场景包含了如下的几个过程：
- 输入查询条件LoginInfoQuery到服务层，并返回LoginInfoBO[]对象数组。
- 展示LoginInfoBO的数据在界面层，并等待修改
- 保存界面层提交的修改之后的LoginInfoBO到数据库
这里就暴露了一个问题，如何让系统了解第3步和第2步的LoginInfoBO就是同一个对象？同样问题也存在BO和PO的转换中，如何把特定的BO转化为特定的PO？这个也就是我们现在为什么摆脱不掉这个POID的根本原因了。一句话，没有POID，我们无法解决对象映射的问题。
真的我们只能通过POID来实现对象映射吗？不是！我们有很多方法可以解决这个问题，只是不如直接使用POID来的方便。比如我们是不是可以用一个Hashtable来保存VP、BO和PO映射关系？当然可以，但是我想我们可以用更好的方法，因为这个问题归根到底就是对象唯一标识（以下简称OID）的问题。
要解决这个问题，我们需要两个条件：一是对象有一个唯一的标识序号OID，二是保存VO和BO、BO和PO对象之间的唯一标识映射关系。直接使用POID可以很容易满足这两个条件，但是带来了极大的程序风险，一旦界面层保存的POID被非法修改的话，程序对这方面的防范很困难，而且很多程序根本就是完全假设界面层POID是可靠的。但是如果程序应用在金融、财务等领域，操作人员就会极有可能有动机去修改这个界面层（尤其是浏览器中）的POID。而且从一般情况下他们会很容易推卸责任（程序bug嘛！要赔偿也是软件开发商赔偿）。所以，可靠的做法就是避免把POID当作通用的OID，而是给每一个对象分配一个OID，同时保证OID之间的简单映射关系。
bigtall给出的OID设计是这样的：所有的DTO对象都继承接口IIdentitable，接口IIdentitable有唯一的属性OID，对象构造的时候，由ClassFactory或者自身的构造函数自动给OID赋值，赋值的算法是这样的：使用session id的简单转换作为key，把POID加入一个校验位（记得身份证号码最后的X吗？）之后的新POID用DES算法加密，这个加密之后的结果就作为BO的OID，如果需要，同样的步骤可以用作BOID到VOID的转换中。用这个算法可以保证不同用户的不同次登录的session id是完全不一样的，所以无法通过简单复制获得OID。其次要配合检查程序，避免用户查询到不属于自己业务范畴的数据，并尽可能对操作对象进行权限检查。
至此，bigtall把DTO的形态变化讲完了，其实还有另外一个重要的概念，DTO的设计。这个设计重要吗？答案是很重要！请看bigtall的“应用程序框架设计之三：数据传递对象的类型和设计”。