按照人类发展的轨迹，第一篇既然是分析和总结。第二篇该是创新与展望了。
struts 框架把中心放在 web 服务器上。其对业务的处理有两种可能：
1） web 服务器有进一步的后台业务处理服务器。可能会用到远程对象访问技术。web 服务器所做的工作是把从浏览器查询字符串传过来的参数序列化成业务服务器能理解的对象。
2） web 服务器没有进一步的业务处理服务器，或者说，业务层并不存在。web 服务器直接操作数据库即可。
第二种情形原本就没有业务层，天生就和我的主张一致。
对第一种情形的分析：
鉴于实际开发中，对业务处理方式和我主张的数据库是一尚不符合，现在我们考虑的业务不作为存储过程，而是 Java / .NET / COM / CORBRA 类。
现在假设为 java 类，当重新用 .net 开发表层时，负责业务的不是数据库，这一层的 OOP 类无法弃掉。虽然业务层负担的东西大部分都无足轻重，然而权限通常都放在这个层，没有它还真的不行。
考虑不用 java 的东西，用 .net 重新开发一套业务层，和 java 方容易抵牾不说，后续维护亦殊增困扰。
另外一种可行的办法是使用 WebService 技术可以达成 java 对象和 .net object 对象之间的互通。然而这个技术实施起来却过于麻烦了。不如我主张的数据库是一更行之有效。数据库是一的做法，把业务放进数据库服务器，安全的躲过开发平台混战的冬天。这一节在数据库是一已经分析过。
所以当我们把着眼点放在业务层上，便发现业务层最好不要以 OOP 的形式存在，而把它存放于数据库作为存储过程。那么 struts 所做的 PO 映射，其意义也就不是想象的那么大了。
原因在于存储过程作为一种过程式的代码片段，其接口也是过程式而非面向对象语言风格的，不具备理解传入对象的生理愿望。
这样一来，我所设想的图景即，传到服务器的形如 query.jsp?param1=value1¶m2=value2 这样的查询参数投递到形如 query(param1,param2) 这样的存储过程。
回顾为什么数据库会把面向对象语言消解了：
1） 因为对象的属性值都存储于数据库，数据库具备翻查对象的属性的能力——不然还谈什么对象存储。既然对象已经存储在数据库，数据库语言天然具备了对属性的读写权。
2） 面向对象的平台正在交战，时局不稳。不如躲在数据库里安全。
现在思考一番避难到数琚库里的对象们。
由于没有 OOP 语言的支持，现在我们仅凭 OO 的脑袋思考，这似乎推翻了维特根斯坦关于语言是思维的极限的论述。 ：）
在数据库里，一类一表格，一行一对象。继承共用主键。这些原则对序列化对象无疑是金不换的定律。
现在考虑方法。
类本身的方法很好办。例如公司，Company 类，和 Company Company.Create(para) 静态方法相仿的是 [row] company_create(para)，用于创建一个公司。
发生继承时的考虑。例如超市型公司，Supermarket 类，其方法应为
[row] supermarket_create(para,para)
begin
company_create(para);
-- create supermarket add-info
end;
实际使用时增加事务的考虑。似可告无虞。
多态。由于 sql 语言支持执行 sql 脚本，使用 exec '... {表名}...'，可以模仿多态。这和反射实现的后期绑定有点相似。
sql 有些自身的语言特性，是面向对象的语言无法企及的。比如多表查询形成的数据行，似是临时创建的一种匿名类。哈希表可以模仿，但模仿出来也不是 OOP 中的类型，得不到继承等等好处。
以上是关于 struts 的 PO 映射的一段思考。如果把焦点移到特定平台的业务服务器，使用 PO 映射还是很不错的。
