一、对NH的理解
NH的主要思路是把关系型数据库表映射到类中，然后通过对类的操作来实现对数据库的间接操作，NH就起到了一个桥梁的作用，这样做的好处在于，在进行软件开发时，更多的去关注数据的处理，而不用关注数据是如何保存和读取的，而且因为数据是类来展现出来的，那么相对于直接用Dataset来说，数据都是"强类型"的（其实Dataset中的数据也是强类型，只不过都是object，需要类型转换，而NH的数据类不需要类型转换），这样可以在编译期发现类型使用和字段使用的错误。

说到这里，我认为这样来处理一般的情况是没有问题，而且很方便，但是，遇到数据的字段有可能变化的情况下（不知道大家有没有做过这样的设计，比如一个单据，今天客户需要增加一个备注，明天可能需要增加一个别的字段，这样的情况下，我一般都提供给客户字段自定义的功能，用户可以自行增加数据表的字段，单据的字段也随之变化），我还没有想到在NH中很理想的解决办法。一个可能的解决方法是，提供尽可能多的未定义的字段，根据需要给这些字段予特定的含义，这样做的代价明显太大，不是我们希望看到的。

二、配置文件和O/R关系的思索

使用NH少不了配置文件，使用配置文件是很清楚的描述数据，但是问题又来了，NH在减少手工编写SQL的同时增加了编写xml配置文件的工作，虽然目前有同仁开发了通过数据库来生成配置文件和数据类的工具（这样的工具我个人认为在思路上有问题，都是从关系模型到对象模型的，这样违背了设计原则，像Hibernate提供的工具就不错，通过对象模型来生成配置文件，进而生成数据模型，虽然有时需要调整数据模型。），如果说编写数据类是为了更准确的描述数据的结构，是必不可少的，配置文件是不是显得有些多余，比如说，数据结构需要调整，那么需要改动程序的两个地方。使用配置文件会使程序代码膨胀起来，给维护带来麻烦，为什么不能用attribute来代替配置文件？我想像中的是这样的形式。

[nh_class(table="cat")]

class Cat{

     public Cat(){}

     [nh_field(column="catname",type="string")]    //type可以省去

     public string Name{set{...} get{...}}

     ......

}