对NHIBERNATE非常了解并且深入了解了NHIBERNATE CONTRIB后,你可以
1,写HBM.XML文件
2,用CONTRIBUTE提供的类库写生成实体类的代码
3,撰写实体类的接口
4,编写测试代码
5,EXPORT SCHEMA
上面的方法显然是最佳的,因为,用一个HBM文件,就搞掂了实体类生成和DDL生成,当然你不需要手工写,有人写了NhiberateQueryAnlazye这个工具,可以点点选选就生成HBM文件
当然,你要是喜欢用VS2003也行,把XSD文档复制到C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Packages\schemas\xml就可以在VS2003中写HBM文件时获得智能感应功能
当然,如果你本身初学NHIBERNATE,你也可以用更传统更接近于你以前写DAL的方式,虽然不建议,但是,做为一种过渡还可以,最终,你都要学会适应NHIBERNATE的开发方式
1,写实体接口
2,写实体类
3,写HBM文件
4,编写测试代码
5,导出DDL
显然,这种方式下,至少你写了实体类和HBM文件,其实,第一种的优点就在于,自动的生成业务实体和数据实体,你只是描述了数据的运行时形式和它的持久化形式,并且描述了二者间的关系
小人拙见:你是写了关系描述,然后生成了实体类和数据表,至于实体类和数据表呢,其实是一样东西,不过呢,一个是运行时形式,一个是持久化形式
OK,也有人或许有意见了,因为很多人是从设计数据表开始,或者你接手的是一个改造工程,数据表是已经存在了的,那么,你的流程可能是下面的了
1,设计数据表
2,找个工具,像CODESMITH,导出实体类
3,写HBM文件
4,编写测试代码
在这里偶不再去说哪个对哪个不对,因为关于对错已经有了太多争执,就如同前一阵子偶写了来自CodeSmith的震撼引起关于先有O还是先有R的争论一样,有许多事都会引起争论,我想,每一种想法,都是从自己那个角度或层面去理解吧
另外,说一个自己觉得有意思的感受,每一次转变,都会带来疑虑,困惑和矛盾,甚至焦虑,就像当初许多人例如我,从ASP转到ASP.NET时,面临一种新的开发模型,面临一种全新的方式,突然发现自己所熟悉的并轻车熟路驾驻驭的那种旧的开发模式不见了的时候,一下子感觉到茫然,难以适应,甚至会刻意想想ASP的好
使用NHIBERNATE也是同样的道理,他也颠覆了我们以前开发DAL层所用的一些手法和策略,甚至可以说,我们以前开发中积累的那些曾经洋洋得意的技巧和经验完全顶不上用场了,而NHIBERNATE文档是极少的,学习的困难 大的,跟以前的模式区别也是大的,这一切,都让你我难以适应,但是,再难适应,也得适应,毕竟NHIBERNATE所代表的是一种趋向,而且,现在你用不熟他的时候,你会感到他晦涩难用,可是,如果你用熟了,你就会发现他的奇妙.
BW:对NHIBERNATE的困惑以及对ORM的困惑,从一个侧面反映出,.NET阵营的开发者,在由以前那种"重形式"的开发过程转为"重加构"的开发过程中成长的烦恼,但这是必然的,举个不太恰当的比喻,这好比让一个生产线的工人去学当设计师,开始是难以适应的,但适应了,就会发现,产品的好坏,不是由生产工人决定,而是由设计师先决定的一样
最后,勉励各位.NETER一句:努力学习,天天向上!别让JAVA阵营再笑话我们了.(偶窃以为JAVA阵营目前是有本钱笑咱们的,毕竟.NET下的应用架构屈指可数,有的几个,也是从JAVA移过来的.而且,相比JAVA而言,在此以前,.NET开发人员的开发模式,确实是令人汗颜的,所以,JAVA人认为偶们是土八路的干活,不过,.NETER就要发力啦)
