在上图中，一个具体的应该在逻辑上被划分为五个部分：数据库、DAO、Repository（业务类仓库）、应用级对象（MBean之类）、前端页面。
数据库
数据库在该开发模式下基本作为数据存储的媒介，同时对于一些应用不好完成的工作，如报表，也是由数据库直接产生（这块不参与本开发模式，后面给出详细的方案）。
对数据库主键的生成策略，可以使用一张表来保存系统中所有表的当前主键值，然后进行相关主键的生成。这样做的好处是可以使得主键生成的效率提高。
|
表名
|
当前主键值
|
备注
|
|
T_XiangMu
|
XM20080108000001
|
|
|
…
|
…
|
|
|
….
|
….
|
|
此外对数据库数据的合法性验证也是需要考虑的。
DAO
该部分主要用户从数据库中获取数据并转换为对应的业务对象或者将业务对象的数据存储到数据库中。
该部分对Java数据类型与数据库数据类型不对应的情况，可以使用相关转换器来完成数据类型的相互转换。该部分仅仅是进行对业务对象的保存、查询、删除等功能（包括更新），而不关系业务类具体要做什么（相当于仅仅转换业务对象 à 数据库 或 数据库信息 à 业务类）。
同时该部分不实现缓存机制，即从该部分提取的数据一定是数据库中的数据。
关于业务对象间关系的维护
在实际的业务对象间存在着很多联系，在该开发模式下，业务对象间的关系的维护不在该层处理，而是在它的上层进行处理（即数据库层不关心实际的业务）。这样做的一个好处是可以将该层做的比较稳定且只处理数据，而不会产生业务与数据库层交叉的情况，同时也保证了每层的功能的单一，便于后面的错误修改。
（这里需要注意事务控制）
Repository（业务对象仓库）
该部分主要用于保存系统中的业务类对象。同时该部分也是业务操作的主要部分（业务操作主要反映为对业务对象的操作）。
这里有两种可选方案：
1、 内存足够时，可以考虑将所有业务类对象都加载进业务对象仓库中。
2、 内存不充足时，可以考虑使用缓存来缓解内存不足的情况。
内存足够时，将所有的业务类对象（可以是主要的业务类对象）加载到内存可以提高系统的整体的响应速度。在该方式中，系统可操作的业务类对象都是在程序启动时就载入到内存的，同时业务操作也是直接对这些唯一的业务类对象进行控制的，这样可以保证在不访问数据库的情况下保证用户得到的数据是最新的。
同时对业务类的增删改查也都是发生在此层。
ApplicationLevelObject（应用级对象）
应用级对象是与最终用户打交道的对象（被页面使用的对象）。
