我对NHibernate的感受（2）：何必到处都virtual

 

我对NHibernate的感受（2）：何必到处都virtual

2009-09-24 15:09 by Jeffrey Zhao, 13533 visits, 收藏, 编辑

上一篇文章主要是在夸NHibernate实现的好，而这篇就完全是来抱怨的了。NHiberante有个毛病，就是如果是和数据库产生映射的类，就要求所有的public成员和protected成员必须是virtual的。请注意这里的要求有两个细节：

• 即使是方法，也必须标记为virtual
• 即时是不和数据库有映射关系的属性，也必须标记为virtual

这就让我觉得无厘头了，为什么没有任何关系的东西也要受到限制？我知道NHiberante要求将属性标记为virtual是为了延迟加载，因为只有这样它才能生成如上一篇文章中那样的延迟代理类，这样就可以实现只在第一次访问属性的时候才进行“加载”操作，从而访问数据库并获得数据，再填充字段。不过我认为这也不是合适的理由，因为这又关没有映射的属性，甚至方法什么事情呢？我在很长一段时间内一直没有想明白这个问题。

直到看了NHibernate开发团队成员Davy Brion的文章《Must Everything be Virtual with NHiberante？》之后，我才了解了他们的设计思路——虽然我还是不认同。我真的不喜欢到处virtual。

要求类中所有的公开成员（public/protected）都是virtual，是因为NHibernate想要保证在“访问任何公开成员”之前，数据已经被加载了。也就是说，无论您是想调用它的ToString方法，还是您自己写的辅助方法/属性，在真正进入您自定义的逻辑之前，数据肯定已经存在了——例如，存在于私有的域字段中：

public class Article
{
    private string m_tagNames
    public virtual string TagNames
    {
        get
        {
            return this.m_tagName;
        }
        set
        {
            this.m_tagNames = value;
        }
    }

    public void DoSomethingWithTagNames()
    { 
        Console.WriteLine(this.m_tagNames);
    }
}

虽然NHibernate可以在TagNames属性第一次访问时加载数据，但是如果我们的DoSomethingWithTagNames方法直接访问m_tagNames字段，数据自然无法加载了。因此，NHibernate必须确保有能力在代理类中覆盖DoSomethingWithTagNames方法才行。这就是virtual方法的由来。

但是在我看来，我们真的有多少情况会去访问私有字段呢？事实上对于大部分情况，我们会使用C#中“自动属性”特性来定义属性，这样自然只有属性，没有字段。即使我们使用了自定义的私有字段来保存属性的值，NHibernate也可以“叮嘱”我们应该访问属性，而不要直接访问私有字段——其实在编程上两者并没有差别。现在这样被强迫的感觉不好。

不过昨天我忽然想到，这似乎也是可以理解NHibernate这么做的原因：因为Hibernate要照顾到Java语言开发人员的使用感受——请注意是Hibernate，没有N。不管怎么说，NHibernate是从Hibernate移植过来的。NHiberante的主力开发人员Oren Eini曾在博客中写道（可惜一时没找到），NHiberante刻意与Hibernate的实现保持同步，这样容易进行双向的同步，例如Hibernate解决了一些bug或性能问题，也可以较为轻易地在NHibernate上修补。

不过这还是没有解释为什么Hibernate要一切都是virutal的原因啊。其实您只要看一下这段Java代码就应该明白了：

public class Product
{
    private String m_tagNames;

    public String getTagNames()
    {
        return this.m_tagNames;
    }

    public String setTagNames(String value)
    {
        this.m_tagNames = value;
    }
}

这是上面C#中Product的等价Java代码。由于Java里没有“属性”概念，因此Java语言自身一直有一个“约定”：getXxx和setXxx两个方法即为一个属性。这个约定用在很多地方，如IDE就会把它当作是一个属性方便设置及导航，框架在进行序列化时候也知道哪些东西是“属性”。这“约定”本没有问题，但是这就给Java开发人员造成了一定困扰：使用起来实在是太麻烦了。例如，Product有个属性叫做ViewCount，我们想要把它加1，在C#中我们可以写：

this.ViewCount++;

而在Java中则必须是：

this.setViewCount(this.getViewCount() + 1);

因此，如果是你的话，在写Java代码的时候，是愿意使用getXxx()这样的方法，还是直接访问类中的私有字段？因此我认为，是Java语言的特性，导致Java开发人员倾向于直接访问类中的私有字段，从而导致Hibernate需要避免未加载的私有字段，进一步导致Hibernate的代理类会去覆盖所有的公开方法（只有方法，因为Java语言没有“属性”）——最终，由于NHibernate在“统一大业”上的策略，使得我们.NET开发人员也必须把所有成员标记为virtual，无论是方法还是属性。

您可能会说，但也没见Java程序员嚷嚷啊。没错，因为在Java语言中，默认情况下所有的成员都是virtual的。而在.NET平台下情况正好相反。因此在我看来，我们这里必须到处标记virtual所造成的不便，和Java语言本身有着非常大联系——我们需承受Java语言所带来的痛苦。

虽然我理解NHibernate，但这又怎能让我满意呢？

哦，对了。在未来的Java 7中，我们可歌可泣的Java语言终于有了a –> property这样的属性访问语法了。

可惜，迟了。

相关文章

• 我对NHibernate的感受（1）：对延迟加载方式的误解
• 我对NHibernate的感受（2）：何必到处都virtual
• 我对NHibernate的感受（3）：有些尴尬的集合支持
• 我对NHibernate的感受（4）：令人欣喜的Interceptor机制