ORM最简单的设计

数据库设计不外乎三种关系

1。一对一

2。一对多

3。多对多

首先，为每个表创建对应的实体类

1。一对一

人员表A，人员信息表B，

那么对象设计在为类A、A业务类，类B，B业务类

A类里有个B类的对象

取B信息的方法写在B业务类中

3。一对多

人员表A，人员信息表B，人员有多个信息

那么对象设计在为类A、A业务类，类B，B业务类

A类里有个B类的对象集合

取B信息的方法写在B业务类中

3。多对多

人员表A，组织机构表B，人员表和组织机构对应关系表C

那么对象设计在为类A、A业务类，类B，B业务类，类C，C业务类

A类里有个B类的对象集合

取B信息的方法写在B业务类中

取A,B关系方法写在C业务类中

同理

B类里有个A类的对象集合

如果多对多的关系表存储的不光是关系，还有其他内容，那么A类或者B类中就是关系对象了，而关系对象存储的是A类和B类对象的集合。一对多同理

 

 

 

方法的定义原则是，取什么对象，就到对应的业务类中取。

按上诉设计，每个业务类只有两基本方法就够了，然后根据两个基本接口查询出的基本对象，可以组合出所有数据库中的数据信息

1。获取所有信息

2。根据主键获取单个信息(多对多关系，需要根据外键获取数据集合,几个外键，几个方法)

例如，要取出一个部门的和人员信息

（1）根据部门ID在B业务类中取得部门信息

（2）根据部门ID在C业务类中取得人员ID

（3）根据人员ID在A业务类中取得人员信息

　　这样就根据三个业务类的简单接口取出了详细信息（取全部其实和单个是一样的，只不过没有部门ID的条件了）

　　这是理想中的ORM定义，可以使程序员完全的不用关注结构型数据、只关注对象数据就可以了，这么做有个局限性是(一般是取出的数据量过大，链接数据库次数过多)，如果这么简单的设计，那么一个部门有200人，那么取这个部门和部门人员的信息需要调200次获取人员的方法根据主键，那么就相当于连接了200次数据库，显然这是不行的，上面所说的只是理想的设计，现实情况还要按理论变化(比如查部门不能关用ID就可以了，还有其他条件等等)。

　　ORM也为程序员由先设计数据库走向只关注设计对象提供了道路。

　　在这里提一下.net中的linq技术，他的对象查询功能为ORM提供了新的生命力。