由NHibernate调用存储过程产生的一些思考

从各种分析来看很多人都不建议在NHibernate中使用存储过程 理由是这样做就违反了面向对象的原则 但是存储过程的存在必然有其道理 别的不说 首先就是其效率要比嵌入代码中的SQL执行效率高 毕竟存储过程是经过编译的 其次在存储过程中还可以实现某些逻辑（当然这样做我觉得有待商榷 毕竟这样子就将业务逻辑写到了数据层里面了）

 

在NHibernate中使用存储过程有两种方法 其一便是使用<sql-insert><sql-update><sql-delete>方法 其二便是使用<sql-query>  前者使用方便 如果将原先嵌入在代码中的SQL通过存储过程来实现 则只需添加这几个节点既可 唯一需要注意的或许就是添加的时候<sql-insert><sql-update><sql-delete>必须注意添加的位置 就个人目前编程遇到过的问题来看 通常是应该放置在映射文件中的最后 而且这几种方法有一个最大的问题 就是映射文件中property定义的顺序必须与存储过程中参数的顺序相同 因为NHibernate在此并没有进行字段和property的比较 而是直接就将其按顺序赋值给各个参数 换言之 这中方法执行的存储过程受限制程度很大 如果某个参数不在某个实体类中存在 那么就无法使用这种方式调用存储过程了

 

而<sql-query>方法 其实某种角度上讲他和前面的是同一个性质 这从他的命名上可以看出来 但同时又由于其高度可自定义性 也可以进行人为的定义 这就使得其可以执行任意的存储过程而不受参数名等等的限制 但是事实上 <sql-query>调用存储过程正如其节点名称所暗示的一样 通常只能进行query操作 因为query通常只需输入某个ID便可 而如果要进行某些比如update操作（通常此类update还涉及到其他表的修改 而不仅仅针对某个表） 由于此时nhibernate并不是通过反射获取实体类的各个property然后根据映射文件给各个参数赋值 而是用户自行给各个参数赋值 所以说这里就没有了nhibernate的ORM的运用

 

其实从某种角度上将 nhibernate这样做更体现了面向对象的以及分层设计的某些原则 在之前做的几个项目中 总是不自觉的将某些复杂的逻辑直接通过存储过程来实现 比如说修改某个入库单 由于修改入库单的同时必然引起对库存数目的影响 因此通过存储过程来同时更新库存数目 同时该存储过程还要做相关的验证 比如说修改的入库数量是否过小以致修改后的库存将为负数等等 这些其实应该在业务逻辑层里面的东西由于贪图便捷直接都写在了存储过程里面 如果使用NHibernate进行开发 那么上面的操作就比较不容易实现（其实不容易只是相对而言的 无非就是无法使用NHibernate的ORM了而已）