免责声明：由于还没有任何好的答案，我决定从我不久前阅读的一篇很棒的博客文章中发布一部分，几乎逐字复制。您可以在此处找到完整的博客文章。所以这里是：
我们可以定义以下两个接口：
public interface IQuery<TResult>
{
}
public interface IQueryHandler<TQuery, TResult> where TQuery : IQuery<TResult>
{
TResult Handle(TQuery query);
}
指定一条消息，该消息使用泛型类型IQuery<TResult>返回的数据定义特定查询。TResult使用之前定义的接口，我们可以定义如下查询消息：
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. 我们可以注入一个完全不同的实现，或者一个包装真实实现的实现，而无需更改UserController（以及该接口的所有其他消费者）。
在指定或注入我们的代码时，该IQuery<TResult>接口为我们提供了编译时支持。IQueryHandlers当我们将FindUsersBySearchTextQuery改为 return时UserInfo[]（通过实现IQuery<UserInfo[]>），UserController将无法编译，因为泛型类型约束 onIQueryHandler<TQuery, TResult>将无法映射FindUsersBySearchTextQuery到User[].
然而，将IQueryHandler接口注入消费者，还有一些不太明显的问题需要解决。我们的消费者的依赖数量可能会变得太大，并且可能导致构造函数过度注入 - 当构造函数接受太多参数时。类执行的查询数量可能会经常变化，这需要不断更改构造函数参数的数量。
IQueryHandlers我们可以通过额外的抽象层来解决必须注入太多的问题。我们创建了一个位于消费者和查询处理程序之间的中介：
public interface IQueryProcessor
{
TResult Process<TResult>(IQuery<TResult> query);
}
这IQueryProcessor是一个具有一个通用方法的非通用接口。正如您在接口定义中看到的那样，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的方法。由于实现了接口，我们可以将它传递给泛型方法。由于 C# 类型推断，编译器能够确定泛型类型，这使我们不必显式声明类型。该方法的返回类型也是已知的。SearchUsersIQueryProcessor.ProcessFindUsersBySearchTextQueryIQuery<User[]>Execute<TResult>(IQuery<TResult> query)Process
现在是IQueryProcessor找对了落实的责任IQueryHandler。这需要一些动态类型，并且可以选择使用依赖注入框架，并且只需几行代码即可完成：
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>此类型用于要求提供的容器类获取该类型的实例。不幸的是，我们需要Handle使用反射调用该方法（在本例中使用 C# 4.0 动态关键字），因为此时无法强制转换处理程序实例，因为通用TQuery参数在编译时不可用。但是，除非Handle方法被重命名或获取其他参数，否则此调用将永远不会失败，如果您愿意，为此类编写单元测试非常容易。使用反射会略有下降，但没什么好担心的。
回答您的一个问题：
所以我正在寻找封装整个查询的替代方案，但仍然足够灵活，以至于您不只是将意大利面条存储库换成命令类的爆炸式增长。
使用这种设计的一个结果是系统中会有很多小类，但是有很多小/集中的类（具有清晰的名称）是一件好事。这种方法显然比在存储库中为同一方法使用不同参数的许多重载要好得多，因为您可以将它们分组到一个查询类中。因此，您获得的查询类仍然比存储库中的方法少得多。