我使用其他技术（CSLA和Subsonic）几年后，又回到了使用NHibernate，发现查询有点令人沮丧，特别是与Subsonic相比。我想知道其他人正在使用什么方法？
Hibernate Query Language对我来说感觉不太对，似乎太像写SQL了，这就是我认为使用ORM工具的原因之一，因此我不必，而且它全部在XML中，这意味着它不利于重构，错误只能在运行时被发现？
Criteria Queries似乎不够流畅。
我看到read Ayende's NHibernate Query Generator是一个有用的工具，人们在使用吗？还有别的东西吗？
LINQ for NHibernate目前仍处于beta版本; 我期待NHibernate 2.1的发布，据说它将最终成为正式版。
大约一个月前，我做了一个有关LINQ for NHibernate的演示，你可能会发现它很有用。我在这里写了一篇博客，包括幻灯片和代码:
LINQ for NHibernate: O/R Mapping in Visual Studio 2008 Slides and Code
想要摆脱XML，可以尝试使用Fluent NHibernate。
Linq2NH还没有完全成熟。核心团队正在开发与NH Contrib中不同的实现方式。对于简单的查询，它可以正常工作。如果要取得最佳结果，建议谨慎使用。
至于如何查询（hql vs. Criteria vs. Linq2NH），在存储库接口上公开表达意图的方法（GetProductsForOrder(Order order)、GetCustomersThatPurchasedProduct(Product product)等），并以最佳方式实现它们。简单的查询可能更易于使用hql，而使用规范模式，则可能会发现Criteria API更适合。这些内容只需保留在您的存储库中，如果测试通过，则实现方式并不重要。
我发现Criteria API很麻烦且限制性强，但是很灵活。HQL更符合我的风格（并且比SQL更好——它是基于对象而不是基于架构的），对于简单的GetX方法，它似乎对我更有效。
我通常默认使用Linq for NHibernate。当我遇到错误或限制时，我会切换到HQL。
如果您将所有查询都放在数据访问类（例如存储库）中，这是一种干净的方法。
public class CustomerRepostitory()
{
//LINQ for NHibernate
public Customer[] FindCustomerByEmail(string email)
{
return (from c in _session.Linq<Customer>() where c.Email == email).FirstOrDefault();
}
//HQL
public Customer[] FindBestBuyers()
{
var q = _session.CreateQuery("...insert complex HQL here...");
return q.List<Customer>();
}
}
您询问了重构的问题。由于IDE已经处理了LINQ，因此对于任何剩余的HQL，扫描这些存储库类并手动更改HQL相当容易。
将HQL放入XML文件是一个好习惯，也许可以看看ReSharper NHIbernate插件现在是否能够处理查询重构？
编写或重构查询（HQL或LINQ）时的一个重大改进是将查找器方法放在单元测试下。这样，您可以快速调整HQL/LINQ，直到获得绿色条形图。编译/测试/反馈循环非常快，特别是如果您使用内存数据库进行测试。
此外，如果您在重构后忘记编辑HQL，则单元测试应该能够快速发现您的错误HQL。
除了LINQ-to-NHibernate和Ayende的NHQG之外，另一种选择是从C#3表达式生成NHibernate表达式/限制。这样可以获得更强类型的Criteria API。
请参见：