读《企业应用架构模式》6--映射到关系数据库

Author:zfive5(zhaozidong)

Email:zfive5@163.com

读完这章，唯一的感觉是如果5年前好好拜读一下，就不至于走许多弯路了,现在产品中也的确好多地方本章里去实践的。从开始领域建模，再到物理数据的存储在单表继承，具体表继承和类表继承，每一种模式应用时也考虑过它们的优与劣。

单表继承：对“标识列”的解释，因为太多的无逻辑的“业务逻辑”，照成“此列无它用”。但考虑到报表还是有选择道理。在场景1中A1类型记录多，A2类型记录少，但只访问A2类型的数据是也要为整体数据付出代价。当然这种可以用索引来解决，但插入在稍后有成了问题。真可谓步步惊心！

具体表继承：隔绝了兄弟姐妹之间相互的影响；但接下来统一又左右为难。克服方法可以引入第3张表或视图。当然也是有困难的。

类表继承：单表继承+具体表继承，但往往西瓜和芝麻真的不能全得。世间真没有Win-Win。

书中作者更倾向第一种，的确它也是我们在产品实践的首选。

关于映射要元数据，我有些其他的想法，因为我们这类人太容易创造新东西，10个我，就会有10个Idea，最后造成要所有的人去熟悉10个Idea，又是成本。是否可以有一种自我描述体系，对象模型+贴身元数据更好些。请注意Attribute和Annotate

select *的问题大家都已经很熟悉了，但深层次的问题是效率问题才是根本。如果你为了select *开脱必然会想到用DataTable[0]["Name"]，但让我用反射看到.NET的DataTable代码:

[ResDescription("DataTableColumnsDescr"), DesignerSerializationVisibility(DesignerSerializationVisibility.Content), ResCategory("DataCategory_Data")]
public DataColumnCollection Columns
{
    get
    {
        return this.columnCollection;
    }
}
 
public DataColumn this[string name]
{
    get
    {
        if (name == null)
        {
            throw ExceptionBuilder.ArgumentNull("name");
        }
        DataColumn column = this.columnFromName[name] as DataColumn;
        if (column == null)
        {
            int num = this.IndexOfCaseInsensitive(name);
            if (0 <= num)
            {