关于compiere的持久层

pshen

很多次有人问起，关于compiere的持久层的设计。
一直觉得，compiere PO层的代码，是比较尴尬。
和持久化相关的代码：PO <- X_** <- M**
当然，还包括DB，CConnection等类。记得很久以前的代码，还包括了大量的VO class,但是看他的VO，感觉又和主流的VO不一样。
现在这部分代码已经不见了。

说他尴尬，是因为整个compiere的CRUD功能，还是包含在AD的框架内。和一些主流的方式不同，会有POJO, DAO,会有Model或者service, compiere不需要这些代码，就能完成基本的功能。
1, 关于X_**类和M**类的作用。
关于他们的作用，答案是：正常情况下，这些类是没用的。
一般程序的写法，po p =new po(), po.setXXX, po.setXXX, po.save()  或者， po = DAO.get(); po.setXXX, po.setXXX, DAO.save(po), 不，compiere不这样做，compiere完全绕开你定义的po类，即便是你在setXXX里，写了天花乱坠的控制代码，也不会被调用（除非你主动调用它），compiere完全按照自己的方式去保存一条记录，不管你有没有为他Generate一个M**文件。
M**类中，只有几个方法，肯定会被调用到，就是Beforesave,aftersave,beforedelete,afterdelete...
这些只是当初做DB Independant的时候，作为Trigger的替代方案。

2，关于业务逻辑层的实现
Compiere的业务逻辑层的实现，基本上是靠workflow和process实现的。最近经常看到些贫血，充血的讨论，比较有意思。对应到compiere，其实关于业务逻辑的代码的位置，也是有点模棱两可的。你可以把一个功能放在M**类中，然后在process中，简单的调用一下，或者你可以把M**作的非常简小，然后在process.doIt代码中，实现你要的功能。（甚至不要M**，完全在process中写）。其实在compiere原始的代码中，都能同时看到这两种风格的代码。
不过，从workflow的document action的实现看起来，compiere还是希望扩充M**。

3，ugly的地方在哪里？
其实原因，说白了也很简单。Compiere的AD一直希望，并且标榜的Zero-Code，无须编码。而实际上，有很多的业务逻辑，依然需要大量的代码，而这些代码，有需要一个简单的方式访问持久层，于是Compiere给了你另一个选择，可以有X_**，不够可以extend，有M**.  但Compiere又要保证Zero-code.
于是你会看到一个class,里面有大量的get,set，而这些除非你用到它，否则，对于保存，修改这些操作，这些method不会被用到。
你有了这些class,并写了很巧妙的代码，给她做了cache，对不起，compiere还是用最低效得方式读出这条数据，并且显示出来。
你改了某个表，某个字段，除非必要，你可以不改你的代码，而你的程序


<未完，待续>

sailin

关于业务逻辑层由workflow与process实现，我对这一点不太理解，能举个例子吗？

xuchanghong

谢谢Q！

sunlongfei_001

x谢谢楼主分享

qishunyong

感谢您的无私奉献