如果我使用Nhibernate HQL而不是查询和连接是不是很糟糕？
我试图从数据库中查询大量数据，但由于需求的复杂性，很难构建查询。一个是我应单独项目两个或多个属于单个列的字段（我不知道这样做，我只是nhibernate中的菜鸟）
我现在想通过HQL来做。好吗？ ：（
答案 0 :(得分：1)
我想根据我的经验附加我的答案：首选Criteria或QueryOver API优先于 HQL 。
这篇文章是论证的起点：http://ayende.com/blog/4042/nhibernate-queries-should-i-use-hql-or-criteria。一个小提取物，引用：
...... HQL是NHibernate公开其大部分功能的方式......它与SQL的相似性意味着它在写入和阅读时非常直观
然而，它最大的弱点是，当您想要使用某些动态条件执行查询时。例如，如果您想要一个包含多个可选搜索字段的搜索页面。 对于这种情况，我们有Criteria API，它允许我们动态，轻松，轻松地撰写查询。 ......
我想签下第二段！迟早，您将把您的应用程序（服务器部分/数据层）移动到某个位置，在那里您将执行一些常规操作。常见的分页，排序，过滤......
要创建有效的 HQL ，需要付出更多努力，因为您将自己完成所有工作。
使用Criteria / QueryOver API，您只需调用标准方法Join，Where，OrderBy ....
不要担心如何将所有碎片放在一起（例如，WHERE x和y ...注入“AND”运算符）。
所以，要知道HQL，但学习Criteria resp QueryOver API ...并使用THEM
编辑：Criteria世界的预测很有趣。
更重要的是，它们可以封装到对象，自定义投影或自定义投影束中。因此，我们可以获得可重用的代码，这可以隐藏实现的一些复杂性。但因为它们是对象，我们可以测试它们，然后依靠它们
我们还可以实现定制的Transformer，它可以带来更多的好处。见example here
预测的一些例子：
答案 1 :(得分：0)
HQL的缺点是它不是类型安全的。就像你在C＃代码中编写TSQL一样。它只是生产臭臭的代码。 如果您的域模型发生了变化，由于代码不同，您很有可能遇到奇怪的异常......
但如果这不是你担心的事情，那取决于你我会说;）