建模 NHibernate 查询

问题描述

通常我会将我的标准/hql 查询放在与实体相关的存储库/dal 类中，但最近我一直在考虑添加另一个表示查询是什么的抽象，这将使我有可能添加基类中所有查询(例如分页)的常见行为等.

Usually I'd put my criterias/hql queries in a repository/dal class related to the entity, but lately I'be been thinking of adding another abstraction that represents what a query is, this would give me the possibility of adding common behavior to all queries (e.g. pagination) in a base class, etc.

现在这些是我的组件；

与nhibernate无关的通用接口:

generic interface not related to nhibernate:

public interface IQuery<T>
{
    IList<T> List();
    T Single();
}

基于标准的查询的示例实现，可以使用 Hql 查询或 nhibernate-linq 查询完成类似的操作

Example implementation of a Criteria based query, something similar could be done with an Hql query, or a nhibernate-linq query

public abstract class CriteriaQuery<T>: IQuery<T>
{
    [Inject]
    public ISessionFactory SessionFactory { protected get; set; }

    protected ISession Session
    {
        get { return SessionFactory.GetCurrentSession(); }
    }

    protected abstract ICriteria Configure(ICriteria criteria);

    [Transaction]
    public virtual IList<T> List()
    {
        var criteria = Session.CreateCriteria(typeof (T));

        return Configure(criteria)
                 .List<T>();
    }

    [Transaction]
    public virtual T Single()
    {
        return Configure(Session.CreateCriteria(typeof(T)))
                .UniqueResult<T>();
    }
}

这里的域特定查询如下所示:

and here a domain specific query would look like:

public interface IGetVideosQuery: IQuery<Video>
{
    IGetVideosQuery Page(int index);
    IGetVideosQuery PageSize(int pageSize);

    IGetVideosQuery AllTime { get; }
    IGetVideosQuery Today { get; }
    IGetVideosQuery LastWeek { get; }
}

对此有什么想法吗?你看到我可能会遇到的可能问题吗?谢谢！

any thoughts on this? possible problems you see I might come across?Thanks!

推荐答案

我走了一条不同的路，CQS.这样做的作用是将我的变异逻辑与查询逻辑分开.

I took a different path, that of CQS. What this does is that it separates my mutating logic from my query logic.

现在，关于如何实现这一点有不同的想法，我选择了这个:

Now, there are different ideas on how to implement this, and I choose this one:

• 我所有的变异逻辑都是使用像 DeactivateUser 和 ChangeRelationAddress 这样的命令激活的.对于这个业务逻辑，我有你描述的普通存储库；

• All my mutation logic is activated using command like DeactivateUser and ChangeRelationAddress. For this business logic, I have normal repositories like you describe;

为了显示数据，我使用了一个完全托管的系统.在这个系统中，我描述了诸如规范模式之类的查询.我描述了基表和字段.查询系统会自动为我创建连接，并使用过滤器定义提供过滤器.

For displaying data, I use a completely managed system. With this system, I describe queries like the Specification Pattern. I describes the base table and the fields. The query system automatically creates the joins for me and with filter definitions I provide filters.

这个系统允许我降低存储库的复杂性，因为我不必考虑用户可能设置的过滤器或ORDER BY.显示此数据的系统会使用 Criteria 自动创建过滤器并为我处理分页.

This system allows me to keep the complexity of my repositories down because I do not have to think about filters a user may set or ORDER BY's. The system that displays this data automatically creates the filters using Criteria and handles paging for me.

也许这样的系统适合你.

Maybe such a system can work for you.

这篇关于建模 NHibernate 查询的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！