由此想起了本科时代学习软件工程时的一个小组大作业。9人做一个论文管理系统，安排了一个同学写界面，然后我把他界面传来的数据做处理。然后问题的关键来了： 我们怎么合作？ 显然我们要规定好什么数据是在界面和我写的逻辑处理类中传输的。比如我需要维护一个用户信息，有 姓名、年龄、性别、工作、电话等等，那么我可以跟他规定，他的界面就做这么几个输入框，然后加个确认按钮，确认完后调用我写好的业务逻辑方法。然后我写这个业务逻辑方法，功能是把这些东西存储到数据库里面。那么我们怎么规定完就可以开工了呢？显然是商量好这个包含 姓名、年龄、性别、工作、电话等等的类后，我们就可以各自分别开工了。这就是POJO（Plain Ordinary Java Object）类： public class Pojo{
private String name;
private int age;
... ... ... ...
public void setName(String name);
... ... ... ...
}
其实在大型软件工程开发组里，每个人的重点都是逻辑层，这里的逻辑层我理解为干事儿的层，通俗的讲就是接受某个数据，然后 做某些处理，最后输出处理后的数据。 但是， 输入需要数据 输出需要数据 这些数据是封装在类里面，省得每次调用方法或者return的时候都得这么写： Service.request(String a, String b, int c, double d, float f, byte g ... ... ... ...);没完了！ （好像return大量数据，你还真的写在一个类里面，因为一次只能return一个东西） 根据POJO类用途不同（也就是用在哪里的不同），分成了如下几个类别： 1、VO（Value Object） 2、PO（Persistant Object） 3、DTO（Data Transfer Object） 其实他们都是POJO的一种，继承关系图（不是代码层面的，是概念层面的，因为一个POJO与一个PO或者VO或者DTO，可能代码完全相同，甚至可能就是同一个类，只不过用在不同的地方）如下：
这里举个简单的例子，PO指的是持久层对象，那么就是作用在持久层的，也就是存储数据的地方。那么自然是与数据库打交道的地方。与数据库打交道的类，通常我们叫做DAO（Database Access Object），他们的关系是这样的：
放大的部分是实际作用的情况，也就是在实际代码里，我们是通过调用Hibernate类来获取PO的。Hibernate类通过JDBC连接远程数据库，获取数据后再将其封装到一个PO里面，传回来。然后我们就可以在DAO写代码进行这个PO的处理了。 如果我们不做任何处理，也就是这个PO里面所有的数据，Service类那边都会用到，那么我们就直接把这个PO进行return。这样在Service那边调用了DAO这个获取PO的方法后，就直接获取PO来进行Service层面的处理。这时候这个PO就不叫做PO了，而叫做VO了。 在简单的程序里可以这样，整个传输过程，VO、PO和DTO都用一个类。因为数据几乎没有太大改动，也不涉及一些性能问题。但当数据库表越来越大，项目越来越大的时候，就得有些区别和技巧了。可能遇到的大项目情况：
(1)、应用服务与数据库不在一台机子上，应用层一个服务器，数据库层一个服务器。 (2)、从数据库取数是容易的，带宽很大，但是计算是困难的，这个数据库CPU很烂。 (3)、从数据库取数是困难的，带宽很小，但是计算是容易的，这个数据库CPU很强。
对于(2)的情况，DAO尽量一次从多个表里面取数，然后在Service层里面合并参数。我在一个学生表取了PO。然后在教师表取了另一个PO，我把2个PO合并得到一个“zjdqc——学生”相关的东西，这个东西显然不是任何一个表的PO。这时候可以叫VO了。 对于(3)的情况，甚至连取个PO都困难了，我们这个表可能有200列，但是需要的信息只需要其中10列，那么获取整个PO是不合理的，浪费了大量带宽。我们定义一个DTO，内容仅仅是PO里面的10列，那么就节省大量带宽了。这就是DTO的存在意义。
其实在小型JavaEE应用里面，这么多细分概念没有太多的用处，徒增烦恼。只有业务复杂度和需求增加到一定量级以后，才会有这些问题，才需要细分这么多功能。总结就是：
1、POJO类是2个或者多个程序员协商好的数据，然后大家拿走这个规定好的东西开始写各自的逻辑处理代码。 2、根据作用的地方不同，你可以把跟数据库打交道的POJO叫做PO，DAO与Service打交道的叫做VO。 3、甚至可以说，数据库设计师与DAO工程师之间用PO交流，DAO工程师与Service工程师之间用VO交流。
更小型的企业不需要这么多层， 把DAO与Service合二为一叫BO，所有的交流全部用同一种POJO，搞定！（大误）
BO是Business Object，中文名业务对象。网络释义繁多： 业务对象(Business Object，BO)是对数据进行检索和处理的组件。是简单的真实世界的软件抽象。业务对象通常位于中间层或者业务逻辑层。业务对象（Business Object）是由第三方开发的，在GeneXus 社区内可获得的知识对象。用其可以在一个应用中自动的加入一个特定的功能来获得增值效应。使知识重用变为可能。比如，如果你要开发一个包含多货币处理的应用，你可以选择使用一个已经开发完成的，包含所有多货币处理功能的业务对象来开始你的开发。使您的开发工作极大的减少。 Remote Data Service 提供默认的中间层业务对象 RDSServer.DataFactory，用于接收客户端请求并提供对指定数据源的读写访问，但不包含任何验证或业务规则逻辑。 BW是做数据部分的（相当于数据建模、存储），BO是将BW中的数据前端展示用的（即报表部分，BO这个产品里面有多种报表实现工具） 1、SAP BW是指 SAP Business Warehouse，也就是SAP 7.0里所指的SAP DW (Data Warehouse)，现在大家都叫DW了，如果你是做BI部分的，肯定要知道DW了和BO了 2、SAP BO说来比较曲折，BO本是一家公司，叫Business Object，同时这个公司有个产品叫Business Object，这个BO公司旨在做动态报表等商业解决方案，后被SAP收购，你可以在百度中搜索下SAP 收购BO，就可以看到具体信息了 3、讲到现在，SAP是有决定将BO整合纳进BOE框架了，基础的BI报表工具他们想仅保留BEx，之前的WAD也不再做后续的技术开发支持，BOE框架是SAP推行的重点，里面含有多个报表开发工具，如Business Object Dashboard,Crystal Report，Web Intelligence等 SAP目前会朝向他们的BPC（财务预算、合并报表）方向、移动化商业智慧解决方案（如智能手机、Ipad等终端）和BOE发展。 目前市场上有多种Ipad前端展示BI报表的工具，相信最近两年是比较热门的（因为ipad火了嘛）