基本上是compiere把所有的表定义放在AD_Table,AD_Column里面，也就是所谓的ad里面。
所以，基本上通过ad的定义，就可以实现对PO的动态管理。
但是，从04年开始，为了适应compiere的db independent的计划，compiere在代码级别加强了po的管理， 基本上由这么几个类层次构成：1，PO.java， 这个是所有PO的基类，由它实现了查询，更新，删除的操作。
尤其是在这个类中，compiere希望由它来实现类似trigger的功能，以移植过去用大量PL/SQL写的trigger代码。 大家看到有beforesave,aftersave等function, 就是用来代替trigger的
2， X_***.java， 这个是可以通过compiere提供的generateModel工具自动产生的，
它继承了PO， 然后基本上相当于一个简单的bean, 是由一些类的get, set组成的。
3， 一般需要一些更复杂的功能，所以大部分的表还会有个对应的M***.java
它继承了X_***.java, 一般实现一些更复杂的业务逻辑。
如果还是一些文档类型的model, 那这个类还会实现DocAction接口
这种类，可以直接应用到workflow中，进行文档状态的转换。
所以，基本上通过ad的定义，就可以实现对PO的动态管理。
但是，从04年开始，为了适应compiere的db independent的计划，compiere在代码级别加强了po的管理， 基本上由这么几个类层次构成：1，PO.java， 这个是所有PO的基类，由它实现了查询，更新，删除的操作。
尤其是在这个类中，compiere希望由它来实现类似trigger的功能，以移植过去用大量PL/SQL写的trigger代码。 大家看到有beforesave,aftersave等function, 就是用来代替trigger的
2， X_***.java， 这个是可以通过compiere提供的generateModel工具自动产生的，
它继承了PO， 然后基本上相当于一个简单的bean, 是由一些类的get, set组成的。
3， 一般需要一些更复杂的功能，所以大部分的表还会有个对应的M***.java
它继承了X_***.java, 一般实现一些更复杂的业务逻辑。
如果还是一些文档类型的model, 那这个类还会实现DocAction接口
这种类，可以直接应用到workflow中，进行文档状态的转换。
