在程序员上看到《企业开发新思维:COID模式简述》,有感

2006年12月这期的程序员上登了这样一篇文章《企业开发新思维:COID模式简述》,看完全文,我大胆总结了一下,主要的思想应该是使用组合ID建立唯一的对象标识符,然后通过使用一些算法来识别对象..其实我觉得这就是把数据库中的多值属性变为组合ID而已.但是我对这种方法持保留的意见。
"COID ( Class-Object Identifier ) 模式是在企业应用系统的开发中,以一种面向对象的思想来进行逻辑数据库的设计和实现，并以此为基础进行系统架构设计和系统功能实现的一系列技术，其关键特征是采用以ClassID + ObjectID组合成全局唯一的COID主键来标识数据对象。"比如可以这样(原文是C,我用Java来写):

 

Long coid; 

BaseObject obj  =  getObject(coid);  // 根据组合ID取得对象 

obj.onOpen();  //  利用多态调用onOpen方法 

 

是的，我们可以通过在getObject方法中进行判断，使用工厂模式来返回具体的对象，但是这等于把数据库的设计问题转为程序的业务逻辑了。比如文章中说的客户可以是Person, Corporation, Department等，的确可以用这种方法调用他们共同的方法。但是如果Person和Corporation有不同的方法呢？这个方法在BaseObject中没有定义呢？Person和Corporation实现了不同的接口呢？那么有些方法就变得不可见了，又怎么根据是Person和Corporation来进行下一步的操作呢？

文章中说的示例数据：

TPerson:

COID		身份证号		姓名	所属组织机构COID
00001000000001		640103197709251010		张翔	000002000000002
00001000000001		740104198710251041		王芳	000000000000000

 

TDepartment:

COID	政府部门	主管部门COID
00003000000001	省国土资源厅	000003000000002
00003000000001	市公安局	000003000000006

 

TOrder:

COID	编号	客户COID
00003000000001	ABC000001	000002000000002
00003000000001	ABC000002	000001000000006

 

那么看TOrder表：可以由客户COID来保存多种类型的客户Id。

如果客户类型很多，那么如果人工查看数据库，就不能马上分辨出是什么客户了。

既然要体现多态性，就是说对不同的客户进行不同的操作，那么如果客户种类很少，那么为什么不为每种客户做一个订单表，进行简单清晰的操作呢？

其实我觉得使用ORM的思想就跟作者比较接近，把数据库中的元组看成对象，使用面向对象的思想来进行数据库的设计，但是有必要使用这样的"多态"么？总觉得是有些违背数据库的设计原则了。

欢迎大家多讨论,多指导

Zou Ang 2006-12-12 13:21 发表评论