关于面向对象设计－－关联
参考：http://www.cnblogs.com/jianyi0115/archive/2007/06/05/772623.html
在构建一个三层架构的系统的时候，实体的设计，是完全的面向对象，还是采用ID关联的平板对象，这是一个问题
一、对象关联情况下实体的设计
/// 单位实体
/// </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>
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特性--延迟加载，只有当真正访问到管理对象的时候才把对象从数据库中取出来。
二。ID关联情况下实体的设计
/// 单位实体
/// </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>
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>
public class UserWithOrgInfo : User
{
private string _OrgName;
/// <summary>
/// 单位名
/// </summary>
public string OrgName
{
get { return _OrgName; }
set { _OrgName = value; }
}
}
或许,你要说,我不需要这么多属性,用户的属性加上单位的属性太多了,UI层显示的时候根本不需要!
OK,我们可以建立一个视图实体:
/// 用户视图实体
/// </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工具。
