[导入]面对对象实体类设计
如何处理多对多的情形
举例:功能点和角色的对应关系。典型的多对多的关系。在传统的关系型数据库中,我们首先会设计两个实体,分别包含了功能点和角色的基本信息,然后设计一个把这两个实体类关联起来的类如下:
class Fuction { string FunctionID; string FuctionName } class Role { string RoleID; string RoleName; } class RoleFunction { string RecordID; string FunctionID; string RoleID; }
据我所知,ORM中从关系数据库中得到对象的时候,也是会产生链接类对象。但是在纯对象中两个类的关联都是天然的。所以可以这样改造上面的设计:
class Fuction { string FunctionID; string FuctionName Role[] Roles; //可以访问功能点的角色的引用 } class Role { string RoleID; string RoleName; Fuction[] Fuctions; //角色可以访问功能点的引用 }
最为重要的是从持久层读出对象的时候,仍然会完好的保持这种引用,修改所引用的对象的属性,所有引用该对象的地方都会改变。所以,按照以上的设计只要持有一个对象本体,就相当于可以快速访问相关的所有类,不会有传统关系型数据库的Join几张表的麻烦了。利用了面对对象的好处。
实体类继承
先在这里声明一下“可以使用组合的地方,不要使用继承”的原则,这样确实可以减少很多麻烦。这里举出的例子说不定不满足上面的原则,但我目前手头就是这个例子,哈哈。这是机构的例子,一个单位中可能有不同的类型的部门,尤其是像医院这样专业性强的单位。不同的部门具有不同的属性。比如住院部就有“病床数”这个属性,而其他的科室没有,那么从面对对象的设计方法入手,自然就有如下的设计 。
class OrganUnit { string OrganID; string OrganName; } class SickRoom : OrganUnit { int BedCount; }
可能是例子过于简单看不多太多的好处,但是当复杂的业务要求机构包含更多的信息并且要求有所区分的时候,会带来好处的。
不可缺少的关联信息类
看上去和前面消除关联类的例子刚好相反,但是有的时候两个类发生关联的时候必然会产生一系列新的属性,若是像第一个例子那样简单的关联在一起,
会导致信息的不完整,还拿第一个例子举例,现在要记录给Role赋权的操作人和操作时间,明显第一个设计会显得力不从心。就需要扩展设计。
class Fuction { string FunctionID; string FuctionName RoleFuction[] Roles; //可以访问功能点的角色的引用 } class Role { string RoleID; string RoleName; RoleFuction[] Fuctions; //角色可以访问功能点的引用 } class RoleFuction { Fuction RelatedFunction; string Creator; DateTime CreatedDateTime; }
似乎Role和Fuction的联系不是那么直接了,那么我们就可以在两个类之间可以加塞我们需要的属性了。
文章来源:http://www.agilelabs.cn/blogs/wind_tower/archive/2005/12/22/294.aspx
浙公网安备 33010602011771号