近日用NHIBERNATE做一个不大的项目，对NHIBERNATE有了第一手的经验，我越使用NHIBERNATE，越喜欢他，但是经过一段时间的琢磨，还是发现NHIBERNATE有以下问题（当然也有可能是我理解不到位），有点骑虎难下的感觉。
1、N-N的关系有点牵强，要两边都将对方加入，另外我查了很多资料、也看了NH的测试用例只说如何建立N-N的关系，却没有感觉如何删除的，总不能建立了就不删除吧。
2、没有办法在N-N关系之间建立关联类，如学生和课程是n-n关系，很显然这2个实体中会有一个关联类，这是UML很早就引入的概念，但是NHIBERNATE好像不能实现，甚至HIBERNATE好像也没有实现。如果不能实现，我们碰到这种情况就只能用弱化的2个1-n关系来表达。这是多么郁闷的事情呀。
3、不能复合查询，在HIBERNATE 很早的版本就实现复合查询，但NHIBERNATE写了这个的测试用例，但是被注释起来了。复合查询，是指以下使用方式：
ICriteria cri = session.CreateCriteria(typeof(SysUser));
cri.Add(Expression.Eq(...)) // 添加查询表达式
ICriteria addrCriteria = cri.CreateCriteria("Address");
addrCriteria.Add(Expresion...)
这样就可以实现复合查询了。
但是NHIBERNATE在ICriteria 接口并没有提供CreateCriteria的方法。
我们起先考虑使用ICriteria而不用hql的原因：
a. 查询/添加/删除/修改 合并成一个页面，因为都是传入一个类似的实体了，因此这个实体就是携带了查询条件了的。
b. 我们实现了页面数据的自动获取，因此通过Expresion.Add(Example...) Example 是NHIBERNATE提供的一个可以通过实体来构建ICriteria的方法。因此如果NHIBERNATE实现的话，我们的代码将减少。但是不幸的就是Example仅仅实现单实体查询。
4、在N-1的关系中的，N方加一条记录，需要load 1方的对象，总觉得很不顺手，但是想想也只能这样。
5、N-1、N-N的关系导致大量无效的查询，但是想想NH的主要之处就是处理关系，但这种关系有不能乱用，有点觉得解决了一些问题，却有带来了问题。至于延时加载，也觉得有点用不上，NH的延时加载必须在同一Session中有效，但总不能上层还套在你的Session里面吧，所以再我看来延时加载就是不加载。
