c# - 精心设计的查询命令和/或规范

Question

我一直在寻找一个很好的解决方案来解决典型存储库模式(不断增长的专门查询方法列表等)所带来的问题。参见:http://ayende.com/blog/3955/repository-is-the-new-singleton。

我真的很喜欢使用命令查询的想法，特别是通过使用规范模式。但是，我对规范的问题是它只涉及简单选择的标准(基本上是 where 子句)，不处理查询的其他问题，例如连接、分组、子集选择或投影等。基本上，许多查询必须经过所有额外的环节才能获得正确的数据集。

(注意:我在命令模式中使用术语“命令”，也称为查询对象。我不是在命令/查询分离中谈论命令，其中查询和命令(更新、删除、插入))

所以我正在寻找封装整个查询的替代方案，但仍然足够灵活，您不仅仅是为了命令类的爆炸而交换意大利面条式存储库。

我已经使用过，例如 Linqspecs，虽然我发现能够为选择标准分配有意义的名称有一些值(value)，但这还不够。也许我正在寻找一种结合多种方法的混合解决方案。

我正在寻找其他人可能已经开发出来的解决方案来解决这个问题，或者解决一个不同的问题，但仍然满足这些要求。在链接的文章中，Ayende 建议直接使用 nHibernate 上下文，但我觉得这在很大程度上使您的业务层复杂化，因为它现在还必须包含查询信息。

一旦等待期结束，我将为此提供赏金。因此，请让您的解决方案有值(value)，并提供良好的解释，我将选择最佳解决方案，并为亚军投票。

注意:我正在寻找基于 ORM 的东西。不必明确是 EF 或 nHibernate，但它们是最常见的并且最适合。如果它可以很容易地适应其他 ORM，那将是一个奖励。 Linq 兼容也很好。

更新:我真的很惊讶这里没有很多好的建议。人们似乎要么完全是 CQRS，要么完全属于 Repository 阵营。我的大多数应用程序都不够复杂，不足以保证 CQRS(大多数 CQRS 倡导者很容易说你不应该使用它)。

更新:这里似乎有点困惑。我不是在寻找新的数据访问技术，而是在寻找业务和数据之间设计合理的接口(interface)。

理想情况下，我正在寻找的是查询对象、规范模式和存储库之间的某种交叉。正如我上面所说，规范模式只处理 where 子句方面，而不处理查询的其他方面，例如连接、子选择等。存储库处理整个查询，但一段时间后会失控.查询对象也处理整个查询，但我不想简单地用查询对象的爆炸式替换存储库。

Answer 1

免责声明:由于还没有任何好的答案，我决定发布我前段时间阅读的一篇很棒的博客文章中的一部分，几乎是逐字复制的。您可以找到完整的博客文章 here .所以这里是:

我们可以定义以下两个接口(interface):

public interface IQuery<TResult>
{
}

public interface IQueryHandler<TQuery, TResult> where TQuery : IQuery<TResult>
{
    TResult Handle(TQuery query);
}

IQuery<TResult>指定一条消息，该消息使用 TResult 返回的数据定义特定查询。泛型。使用之前定义的接口(interface)，我们可以定义这样的查询消息:

public class FindUsersBySearchTextQuery : IQuery<User[]>
{
    public string SearchText { get; set; }
    public bool IncludeInactiveUsers { get; set; }
}

这个类定义了一个带有两个参数的查询操作，这将产生一个 User 的数组。对象。处理此消息的类可以定义如下:

public class FindUsersBySearchTextQueryHandler
    : IQueryHandler<FindUsersBySearchTextQuery, User[]>
{
    private readonly NorthwindUnitOfWork db;

    public FindUsersBySearchTextQueryHandler(NorthwindUnitOfWork db)
    {
        this.db = db;
    }

    public User[] Handle(FindUsersBySearchTextQuery query)
    {
        return db.Users.Where(x => x.Name.Contains(query.SearchText)).ToArray();
    }
}

我们现在可以让消费者依赖泛型 IQueryHandler界面:

public class UserController : Controller
{
    IQueryHandler<FindUsersBySearchTextQuery, User[]> findUsersBySearchTextHandler;

    public UserController(
        IQueryHandler<FindUsersBySearchTextQuery, User[]> findUsersBySearchTextHandler)
    {
        this.findUsersBySearchTextHandler = findUsersBySearchTextHandler;
    }

    public View SearchUsers(string searchString)
    {
        var query = new FindUsersBySearchTextQuery
        {
            SearchText = searchString,
            IncludeInactiveUsers = false
        };

        User[] users = this.findUsersBySearchTextHandler.Handle(query);    
        return View(users);
    }
}

该模型立即为我们提供了很大的灵活性，因为我们现在可以决定向 UserController 注入(inject)什么内容。 .我们可以注入(inject)一个完全不同的实现，或者一个包装真实实现的实现，而无需对 UserController 进行更改。 (以及该接口(interface)的所有其他使用者)。
IQuery<TResult>接口(interface)在指定或注入(inject)时为我们提供编译时支持 IQueryHandlers在我们的代码中。当我们更改 FindUsersBySearchTextQuery返回 UserInfo[]相反(通过实现 IQuery<UserInfo[]> )， UserController将无法编译，因为 IQueryHandler<TQuery, TResult> 上的泛型类型约束将无法映射 FindUsersBySearchTextQuery至 User[] .

注入(inject) IQueryHandler然而，与消费者的接口(interface)仍有一些不太明显的问题需要解决。我们的消费者的依赖项数量可能会变得太大，并可能导致构造函数过度注入(inject) - 当构造函数接受太多参数时。一个类执行的查询数量可能会经常变化，这需要不断更改构造函数参数的数量。

我们可以解决注入(inject)过多的问题 IQueryHandlers带有额外的抽象层。我们创建了一个位于消费者和查询处理程序之间的中介:

public interface IQueryProcessor
{
    TResult Process<TResult>(IQuery<TResult> query);
}

IQueryProcessor是一个具有一个泛型方法的非泛型接口(interface)。正如您在接口(interface)定义中所见， IQueryProcessor取决于 IQuery<TResult>界面。这使我们能够在依赖于 IQueryProcessor 的消费者中获得编译时支持。 .让我们重写 UserController使用新 IQueryProcessor :

public class UserController : Controller
{
    private IQueryProcessor queryProcessor;

    public UserController(IQueryProcessor queryProcessor)
    {
        this.queryProcessor = queryProcessor;
    }

    public View SearchUsers(string searchString)
    {
        var query = new FindUsersBySearchTextQuery
        {
            SearchText = searchString,
            IncludeInactiveUsers = false
        };

        // Note how we omit the generic type argument,
        // but still have type safety.
        User[] users = this.queryProcessor.Process(query);

        return this.View(users);
    }
}

UserController现在取决于 IQueryProcessor可以处理我们所有的查询。 UserController的 SearchUsers方法调用 IQueryProcessor.Process方法传入一个初始化的查询对象。自 FindUsersBySearchTextQuery实现 IQuery<User[]>接口(interface)，我们可以将它传递给泛型 Execute<TResult>(IQuery<TResult> query)方法。由于 C# 类型推断，编译器能够确定泛型类型，这使我们不必显式声明类型。 Process的返回类型方法也是众所周知的。

现在是执行 IQueryProcessor 的责任找到合适的 IQueryHandler .这需要一些动态类型，并可选择使用依赖注入(inject)框架，并且只需几行代码即可完成:

sealed class QueryProcessor : IQueryProcessor
{
    private readonly Container container;

    public QueryProcessor(Container container)
    {
        this.container = container;
    }

    [DebuggerStepThrough]
    public TResult Process<TResult>(IQuery<TResult> query)
    {
        var handlerType = typeof(IQueryHandler<,>)
            .MakeGenericType(query.GetType(), typeof(TResult));

        dynamic handler = container.GetInstance(handlerType);

        return handler.Handle((dynamic)query);
    }
}

QueryProcessor类构造一个特定的 IQueryHandler<TQuery, TResult> type 基于提供的查询实例的类型。此类型用于要求提供的容器类获取该类型的实例。不幸的是，我们需要调用 Handle使用反射的方法(在这种情况下使用 C# 4.0 dymamic 关键字)，因为此时不可能强制转换处理程序实例，因为泛型 TQuery参数在编译时不可用。但是，除非 Handle方法重命名或获取其他参数，此调用永远不会失败，如果您愿意，可以很容易地为此类编写单元测试。使用反射会略有下降，但没什么好担心的。

回答您的问题之一:

So I'm looking for alternatives that encapsulate the entire query, but still flexible enough that you're not just swapping spaghetti Repositories for an explosion of command classes.

使用这种设计的结果是系统中会有很多小类，但是有很多小类/重点类(名称清晰)是一件好事。这种方法显然比在存储库中为同一方法使用许多具有不同参数的重载要好得多，因为您可以将它们分组到一个查询类中。因此，与存储库中的方法相比，您获得的查询类仍然少得多。