关于该方案的基本设计思路是这样的：
首先，代码生成的基础还是数据库表，但是，提供一个从XMI生成Tables的工具，以支持从UML类图到对应Tables的自动生成，并支持以自定义类型作为其他类的属性的数据类型；
接着，基于这些Tables，可以生成映射到DomainObjects及为其增加持久化支持的Xml Profile，Xml Profile For Domain Objects基本和其他的o/r映射的xml文件类似，Xml Profile For Persistation则是独立出来的提供关于各个DomainObject的CRUD及其它复杂的自定义的与对应数据库表存取相关的操作，附加操作需要关联到给定sql语句或者存储过程；
然后，基于上面生成并根据需要修改的Xml Profiles，由框架辅助工具生成相应的DomainObjects和Persisters的接口和默认实现，这里生成接口（各个层面的代码都先生成接口）的目的一是使参数和返回数据采用接口而与具体的代码实现分离，二为了支持各个层面的AOP，目前来讲，个人觉得在业务层织入就够了，原则上不应该修改生成的源码，如果需要织入，撰写需要的织入代码并修改Profile就可以了；
在上一步生成并扩充的Xml Profile For Persistation的基础上，自动生成默认的Xml Profile For Business/AOP/Transaction，默认生成的代码只指定由数据库外键指定的级联删除事务，可由用户扩充事务及AOP支持的配置信息；
最后就可以由框架提供的Business Manager来解析并执行具体的业务调用了，对于，特殊业务代码，可以采用AOP的方式，织入或代替默认生成的代码中的部分函数或类，所有UI层的业务代码调用原则上只需访问调用Business Manager的统一接口就可以了。