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

数据库建模完成后,我们需要根据数据库模型使用某一个种面向对象语言设计出对象模型,对象模型与数据库模型的区别在于对象模型主要是为了使设计过程更加面向对象,抽象、继承、多态、封装,对象模型中的实体与数据库模型中的实体可能基本一致,但也只是对于小型的、业务不太复杂的系统才能可能，对于大型的复杂系统（比如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厂商的投入成本。