需要在一个已经在运行中的系统中引入一个（新增的）父类的情况很常见。
假设在这个系统中我们原先就已经使用了 ORM 框架，而使用的 ORM 框架可能支持继承映射特性。继承映射大致有三种方式：
- TPH：Table Per Hierarchy
- TPT：Table Per Type
- TPC：Table Per Concrete Type
如何在这几种方式中进行选择？对于一个已经在运行的系统来说，其中有一个重要因素需要考虑：怎么减少对数据库模型（Schema）的修改？
显然，使用 TPC 方式对数据库模型（Schema）的影响最小。
不要小看这一点。有人说，SQL 数据库之所以取得巨大的成功，是因为它提供了一个标准的集成机制。往往很多代码、系统都是和 SQL 数据库模型耦合在一起的，对数据库 Schema 的修改往往牵一发而动全身。对于已经在使用的系统，重构还是一小步一小步地来好一些。下面我们就先看看怎么用 TPC 的方式来搞吧。
我们假设现在系统中有两个类，一个是 Store（门店），一个是 Agency（代理）。
其中 Store 的代码如下：
using System;
namespace NHibernateTest.Domain.Model
{
public class Store
{
public Store ()
{
}
public virtual int StoreId { get; set; }
public virtual string StoreName { get; set; }
public virtual string Location { get; set; }
}
}
另外一个类 Agency 的代码如下：
using System;
namespace NHibernateTest.Domain.Model
{
public class Agency
{
public Agency ()
{
}
public virtual int AgencyId { get; set; }
public virtual string AgencyName { get; set; }
public virtual string Location { get; set; }
}
}
假设我们的系统的使用了 NHiberante 作为 ORM 框架。Store 的 OR 映射文件：
Agency 的映射文件如下：
现在，我们发现需要引入一个父类 Organization（组织）。
至于为什么要引入？这里不多解释，请自行脑补吧。
如果使用 TPC 方式，对代码的修改非常简单。
Organization 的代码：
using System;
namespace NHibernateTest.Domain.Model
{
public abstract class Organization
{
static Random rand = new Random ();
public static int NextOrganizationId ()
{
return rand.Next ();
}
public Organization ()
{
}
public virtual int OrganizationId { get; set; }
public virtual string Name { get; set; }
public virtual string Location { get; set; }
}
}
对 Store 的修改如下：
using System;
namespace NHibernateTest.Domain.Model
{
public class Store : Organization
{
public Store ()
{
}
// public virtual int StoreId { get; set; }
//
// public virtual string StoreName { get; set; }
//
// public virtual string Location { get; set; }
public virtual int StoreId {
get { return OrganizationId; }
set { OrganizationId = value; }
}
public virtual string StoreName {
get { return Name; }
set { Name = value; }
}
}
}
对 Agency 的修改如下：
using System;
namespace NHibernateTest.Domain.Model
{
public class Agency : Organization
{
public Agency ()
{
}
// public virtual int AgencyId { get; set; }
//
// public virtual string AgencyName { get; set; }
//
// public virtual string Location { get; set; }
public virtual int AgencyId {
get{ return OrganizationId; }
set{ OrganizationId = value; }
}
public virtual string AgencyName {
get { return Name; }
set { Name = value; }
}
}
}
原来 Store 和 Agency 的映射文件可以干掉了。新的 Organization 的映射文件如下：
测试代码片段如下：
public static void TestOrgs ()
{
using (ISession session = _sessionFactory.OpenSession ())
using (ITransaction transaction = session.BeginTransaction ()) {
Store s = new Store ();
//***********
s.OrganizationId = Organization.NextOrganizationId ();
//
s.StoreName = Guid.NewGuid ().ToString ();
s.Location = Guid.NewGuid ().ToString ();
session.Save (s);
Agency a = new Agency ();
//***********
a.OrganizationId = Organization.NextOrganizationId ();
//
a.AgencyName = Guid.NewGuid ().ToString ();
a.Location = Guid.NewGuid ().ToString ();
session.Save (a);
transaction.Commit ();
}
}
上面假设原来 Store 和 Agency 两个实体在数据库中的主键列名都是 Id，分别映射到代码中 StoreId 和 AgencyId。这种情况下，我们看看使用 TPC 方式为它们引入一个共同的父类，我们做了哪些修改：
-
修改了 Id 的产生机制。
这里出于演示的目的，将 Organization（Store 和 Agency）的 Id 改成了 assigned 方式，并在 Organization 的代码中写了一个演示性的 Id 生成方法 NextOrganizationId（随机产生一个整数作为 Id，不要用在正式的生产代码中）。其实还有其他的 Id 产生机制可以选的；
新增了一个 Organization 抽象父类。将 Store 和 Agency 概念相同的属性提升到这个父类中；
修改了 Store 和 Agency 的代码，让它们分别继承 Organization，并将它们原有的一些属性访问操作委托给父类实现。
除此之外，就没有别的了。特别需要注意的是：数据库 Schema 可能几乎没有做修改。这里说可能几乎，是因为：原来的 Id 产生器是 native 的，而对不同的底层数据库来着，native 的实现机制可能是不一样的。比如 MS SQL Server 和 MySQL 默认是使用了自增类型的字段。这时候就需要把 Id 字段的自增属性去掉。
当然，这里说的只是数据库的 Schema （几乎）不变，但是系统遗留的已有数据（Store 和 Agency）可能存在 Id 冲突，所以数据迁移还是要做的。
还有，如果原来的（Store 和 Agency 对应的）两个数据表中，Id 的字段名不是 Id，而是 StoreId 和 AgencyId，那 Schema 可能就需要改了。
以上是使用 NHiberante 举例，EF 应该也差不多。关于 EF 的继承映射支持，可以自行 Google。也可以看看这篇文章：
http://www.cnblogs.com/oppoic/p/ef_tph_tpt_tpc_inheritance.html