HIS系统患者实体OO设计的一点思考

软件开发的生命周期中，数据库建模后,在某个数据库系统中造成相对应的表,以后再根据数据库模型设计相关的业务对象及其关系.这实际上是进行了两次设计,一次是数据库模型设计,数据库模型设计是根据现实业务提取出来的模型,这个模型最终是产生了业务数据之间的关系以及业务数据的存储方式.

数据库建模完成后,咱们须要根据数据库模型使用某一个种面向对象语言设计出对象模型,对象模型与数据库模型的区别在于对象模型主要是为了使设计过程更加面向对象,抽象、继承、多态、封装,对象模型中的实体与数据库模型中的实体可能基本一致,但也只是对于小型的、业务不太复杂的系统才能可能，对于大型的复杂系统（好比HIS系统），对象模型与数据库模型中的实体要一致则基本不可能.

两次不一样角度、不一样层面的设计（数据库模型关注存储，对象模型关注OO表达）增长了咱们的工做量，并且两次设计以后产生了差别,最终致使了数据库中的实体（表）与对象模型中的实体（对象）产生不一致了，属性字段（数据库中的字段、对象中属性）也可能不一致了，在实际的开发中，必须很熟悉对象的属性对应到哪一个表上的字段，这无疑增长了咱们的学习成本。

也许，这就是各类ORM框架（如Nhibernate、Entity Framework）的主要目标，目前，ORM框架有轻型的，有重量级的，ORM框架的优劣咱们先放一边，从众多项目使用状况来说，有成功的、也有失败的，从工程师对ORM框架的态度上来看，有嗤之以鼻者、也有疯狂追捧的。每一个人的计算方法不同，各类滋味，还自有本身去体会才行。

话说回来，咱们仍是回到原始，在没有ORM框架的状况下，如何设计好出色的OO模型，我这里以HIS系统中的患者基本信息来举例。

在数据库系统设计中，在遵循了数据库范式的同时，为了提升效率、减小服务器压力，会进行必定的冗余，好比次例的HIS系统中，患者的基本信息会存储在一种表中，可是对象设计以下：

 

BaseClass类是抽象的基本类，存储了在业务系统中方便查找患者的五笔码、拼音码、自定义码等，PatientInfo类包含了患者的姓名性别、入院相关信息、费用信息、地址信息、各类编号等，而这些信息又分了几个单独的实体和枚举，有患者性别枚举，患者状态信息枚举，以及定位患者的位置信息类（Plocation类），存储患者各类编号的类（PID类），存储与患者相关的金钱有关的类（MoneyInfo类），这些类的属性对对应到数据库患者基本信息表中的每一个列。

 

结后语：

我的对ORM框架是彻底接受而且很是喜欢的，但我认为不是每一个项目、每一个系统都适合使用ORM，若是能把对象模型设计好仍是能有一个维护性好、扩展性好、新人学习成本低的系统。目前我认为对于HIS系统来讲，不太适合使用ORM框架，由于HIS业务太复杂，需求不少，变化很大，而通常的HIS厂商每每须要投入开发人员在客户现场进行本地化开发，在现场加字段、加表是常有的事情，这使得HIS厂商必须雇佣软件开发水平较高的人员在驻场开发，使用ORM增长了现场人员的学习压力，间接提升了HIS厂商的投入成本。