DBO -- 实体设计 -- 对象关联还是ID关联

在构建一个三层架构的系统的时候，实体的设计，是完全的面向对象，还是采用ID关联的平板对象，这是一个问题。写一点个人的观点。

假设在一个用户管理系统中，存在单位和用户两个实体,

表结构如下：




我们先看对象关联情况下实体的设计：

///   <summary>
     ///  单位实体
     ///   </summary>
     public   class  Org
    {
         private   int  _OrgId;
         ///   <summary>
         ///  单位id
         ///   </summary>
         public   int  OrgId
        {
             get  {  return  _OrgId; }
             set  { _OrgId  =  value; }
        }

         private   string  _OrgName;
         ///   <summary>
         ///  单位名
         ///   </summary>
         public   string  OrgName
        {
             get  {  return  _OrgName; }
             set  { _OrgName  =  value; }
        }

         private  Org _ParentOrg;
         ///   <summary>
         ///  父单位
         ///   </summary>
         public  Org ParentOrg
        {
             get  {  return  _ParentOrg; }
             set  { _ParentOrg  =  value; }
        }

         private  IList < Org >  _ChildrenOrg;
         ///   <summary>
         ///  子单位列表
         ///   </summary>
         public  IList < Org >  ChildrenOrg
        {
             get  {  return  _ChildrenOrg; }
             set  { _ChildrenOrg  =  value; }
        }

         private  IList < User >  _Users;
         ///   <summary>
         ///  单位的用户
         ///   </summary>
         public  IList < User >  Users
        {
             get  {  return  _Users; }
             set  { _Users  =  value; }
        }
    }

  ///   <summary>
     ///  用户实体
     ///   </summary>
     public   class  User
    {
         private   int  _UserId;
         ///   <summary>
         ///  用户id
         ///   </summary>
         public   int  UserId
        {
             get  {  return  _UserId; }
             set  { _UserId  =  value; }
        }
        
         private   string  _UserName;
         ///   <summary>
         ///  用户名
         ///   </summary>
         public   string  UserName
        {
             get  {  return  _UserName; }
             set  { _UserName  =  value; }
        }

         private  Org _OwnerOrg;
         ///   <summary>
         ///  用户所属的单位
         ///   </summary>
         public  Org OwnerOrg
        {
             get  {  return  _OwnerOrg; }
             set  { _OwnerOrg  =  value; }
        }

这是两个非常面向对象的实体--数据实体，那么我们在使用的时候会遇到什么问题呢？

对象关联在一起，不可避免的遇到关联加载的问题--当我获取一个用户实体的时候，为满足完整性，我也必须从数据库中取出一个单位实体。

为了解决这么问题，大多数流行的ORM框架提供了lazy-load特性--延迟加载，只有当真正访问到管理对象的时候才把对象从数据库中取出来。

看似问题解决了，仔细分析一下，那些延迟加载实现的怎么样？？？

实现lazy-load的大多数方法都要求侵入实体代码，如NHibanate，它的实体类属性要求必须是虚属性（最新版的NH），为什么？应为它要延迟加载，就必须拦截属性的调用（好像它是利用castle的动态代理实现的）。

可能你会说，实体类属性都写成虚的（virtual）还是可以接受的，那么，我们看另外的问题：

问题1：要延迟加载，取出一个实体后，数据库连接一定不能立即关闭， 数据库连接关闭了，代码还怎么延迟访问数据库取数据？于是，数据库连接关闭的代码必须写到UI层。

问题1：现在流行的一下AOP，IOC框架很多都支持分布式部署，在分布式部署的情况下，我们考虑关联实体会怎么样？远程的一个客户端取到实体，每次访问其他关系实体属性时都会在一次请求服务器端！
你可能会说，在分布式部署的情况下我不采用延迟加载不就可以了。请注意一点：
这里所说的在AOP框架支持下的分布式部署，是“透明”的分布式部署，即UI层开发的时候不需要要考虑分布式的问题（那么，你是不是要延迟加载了），系统开发好了，如果需要，可以通过配置AOP框架实现分布式，这时，原有的采用延迟加载的页面就会碰到问题。


我们再看ID关联情况下实体的设计：

///   <summary>
     ///  单位实体
     ///   </summary>
     public   class  Org
    {
         private   int  _OrgId;
         ///   <summary>
         ///  单位id
         ///   </summary>
         public   int  OrgId
        {
             get  {  return  _OrgId; }
             set  { _OrgId  =  value; }
        }

         private   string  _OrgName;
         ///   <summary>
         ///  单位名
         ///   </summary>
         public   string  OrgName
        {
             get  {  return  _OrgName; }
             set  { _OrgName  =  value; }
        }

         private   int  _ParentId;
         ///   <summary>
         ///  父单位id
         ///   </summary>
         public   int  ParentId
        {
             get  {  return  _ParentId; }
             set  { _ParentId  =  value; }
        }     

    }

  ///   <summary>
     ///  用户实体
     ///   </summary>
     public   class  User
    {
         private   int  _UserId;
         ///   <summary>
         ///  用户id
         ///   </summary>
         public   int  UserId
        {
             get  {  return  _UserId; }
             set  { _UserId  =  value; }
        }

         private   int  _orgId;
         ///   <summary>
         ///  所属单位id
         ///   </summary>
         public   int  OrgId
        {
             get  {  return  _orgId; }
             set  { _orgId  =  value; }
        }

         private   string  _UserName;
         ///   <summary>
         ///  用户名
         ///   </summary>
         public   string  UserName
        {
             get  {  return  _UserName; }
             set  { _UserName  =  value; }
        }
        
    }

首先从代码上，比上面的简单些吧。

这样的实体，虽然有那么一点不“面向对象”，但绝对避免了“面向对象”时遇到的问题。

我们这群人的工作，总是在 发现问题-〉解决问题-〉引起新的问题 -〉解决问题 中度过的。

OK，ID关联的实体设计方法同样遇到了新问题：我要处理多表的数据怎么办？我要跨表查询怎么办？

解决方案就是：采用关联实体，或者称为视图实体.

举个例子: UI层要显示一个用户列表, 同时显示出每个用户所属的组织机构名 , 怎么办?
Easy! 只要设计一个关联实体:

   ///   <summary>
     ///  具有单位名称的用户关联实体
     ///   </summary>
     public   class  UserWithOrgInfo : User
    {
         private   string  _OrgName;
         ///   <summary>
         ///  单位名
         ///   </summary>
         public   string  OrgName
        {
             get  {  return  _OrgName; }
             set  { _OrgName  =  value; }
        }
    }

或许,你要说,我不需要这么多属性,用户的属性加上单位的属性太多了,UI层显示的时候根本不需要!
OK,我们可以建立一个视图实体:

  ///   <summary>
     ///  用户视图实体
     ///   </summary>
     public   class  UserView
    {
         private   string  _UserName;
         ///   <summary>
         ///  用户名
         ///   </summary>
         public   string  UserName
        {
             get  {  return  _UserName; }
             set  { _UserName  =  value; }
        }

         private   string  _OrgName;
         ///   <summary>
         ///  单位名
         ///   </summary>
         public   string  OrgName
        {
             get  {  return  _OrgName; }
             set  { _OrgName  =  value; }
        }

    }

这下满足了吧！ 需要几个属性,就返回几个属性.

问题解决了!!!!!!!!!

但是新的问题又来了:

采用ID关联设计实体,仍然要写大量的数据库操作代码,如果采用一些ORM框架,他们对ID关联的实体设计又没有考虑到进行支持,因为现有的ORM框架大多都是为了应对“面向对象”的实体设计而开发的. NHibenate,IBatics.net,NBear，DLinq皆如此。


这就是DBO的由来，没有人会做无用功，也不会有人喜欢发明一个一样的轮子，每个轮子都应该有它适合走的道路。

DBO，为ID关联实体设计提供数据操作支持的ORM工具。

DBO从2007-5-20开始开发，基本功能完成，不足之处总归是有的，任者见任，智者见智，欢迎有兴趣的朋友提出意见。

DBO 介绍，见：

http://www.cnblogs.com/jianyi0115/archive/2007/06/04/771325.html