昨天看到听棠.NET对于学习NHibernate 提出了非常宝贵的意见，希望每次的研究或者玩一个工具都不要放弃，这点我绝对赞成（我们很多人都是一种3分钟的热度，老外就比较钻研一点，任何一个东西学精通了都很牛），也许你说中了很多点，但是也有些你没有说中，我经历了一些开发，虽然还不是很丰富，关于架构也略知一二。现在所在的公司，也有一些OR Mapping 的工具、代码，我自己没有达到他的水平，当然也写不出这样的代码。不过，至于我为什么要学习NHibernate, 你觉得 Nhibernate不好，但是 Hibernate 都已经有3.0了，为什么能够发展下去？为什么微软也在搞自己的OR Mapping 工具，呵，盲目崇拜、突出自己的水平，有必要吗？
相信熟悉Java的同志们都知道JavaEye这个网站，我想很多学习.Net的人也知道这个。她的创始人，Robbin，曾经写过为什么要学习Hibernate，以及如何学习Hibernate，最近刚刚出版的《深入浅出Hibernate》虽然他不是作者，但是我想他一定在这个过程中贡献过自己的力量（他们几个都很熟悉）。可以参考一下他的文章，虽然是2年前的了！听CSDN的编辑GiGix吹过一次牛，虽然他说的不一定正确，他提到了很多技术，很多很大的名词，最终总结了一句“古已有之”！
至于我，我自从学习开发软件以来，一直在考虑我们的OOA和OOD都是怎么做的，到底这些东西都是为了做个漂亮、专业的报告而搞出一点花样吗，还是为了真正解决项目中的问题。任何项目一开始，正规的做法都是做需求，做用例，也开始了画类图、对象图、序列图、设计界面、设计数据库，这样就结束了设计！但是真正开始了编码的时候，除了界面、数据库，其它几乎全部都抛弃了！为什么抛弃了，因为发现我们开始编码以后，我们就回到了Table模式，DataSet模式进行思考问题，这个表存放什么字段，两个表之间如何关联，就是Justin Gehtland所谓的tabular programming；而不是在考虑两个业务对象之间如何交互，如何发送消息了。为什么在OOA和OOD之间出现了这么大鸿沟呢？我们设计的类图和数据库的关系图、以及后续的Coding之间是否可以很好的过渡呢？OR Mapping，正如他的名字一样，Object Relationship Mapping，这里的O就是我们平时所说的面向对象，这里的R就是我们说的关系数据库，既然NHibernate生来就是为了解决这问题的，为什么不学习一下？了解一下他是怎么运作的。Martin Fowler先生在《企业应用架构模式》中极力推崇使用Domain Model进行领域模型的设计和开发，然后平滑的过渡、映射到数据库，我想NHibnernate也许能帮这个忙！
至于你说的SQL或者HQL的迷阵也好，还是性能问题也好，我觉得这个东西是其次的，都可以经过一段时间的熟练以后过渡过来，真正的软件设计的目标和目的肯定不是这个，而是如何实现项目的最终目标，满足客户的需求，保证开发人员对于需求的把握更佳！而不是每次来了Change Request以后，就开始了修改庞大的修改SQL语句的工程，也许有些片面，如果项目要Close了，势必要进行更新所有的类图，序列图和其他大量的文档，而此时，类图、序列图和其他文档反而成了一种累赘，那么为什么我们要他呢？
所以，总结一句，我是希望通过学习HNhibernate掌握持久层设计应该把握的原则和技巧，深刻地理解对象持久层设计理念！试图寻找一个更好的软件开发思路!!
