免责声明：由于还没有任何很好的答案，我决定从我不久前阅读的一篇很棒的博客文章中发布一部分，几乎逐字复制。您可以找到完整的博客文章here。所以这里是：
我们可以定义如下两个接口：
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 改为返回UserInfo[]（通过实现IQuery<UserInfo[]>）时，UserController 将无法编译，因为IQueryHandler<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 的SearchUsers 方法调用IQueryProcessor.Process 方法，传入一个初始化的查询对象。由于FindUsersBySearchTextQuery 实现了IQuery<User[]> 接口，我们可以将它传递给通用的Execute<TResult>(IQuery<TResult> query) 方法。由于 C# 类型推断，编译器能够确定泛型类型，这使我们不必显式声明类型。 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 dymamic 关键字），因为此时无法强制转换处理程序实例，因为通用TQuery 参数在编译时不可用时间。但是，除非 Handle 方法被重命名或获取其他参数，否则此调用将永远不会失败，如果您愿意，为此类编写单元测试非常容易。使用反射会略有下降，但没什么好担心的。
回答您的一个问题：
所以我正在寻找封装整个查询的替代方案，但是
仍然足够灵活，你不只是交换意大利面
命令类爆炸式存储库。
使用这种设计的一个结果是系统中会有很多小类，但是有很多小类/重点类（名称清晰）是一件好事。这种方法显然比在存储库中为同一方法具有不同参数的许多重载要好得多，因为您可以将它们分组到一个查询类中。因此，您获得的查询类仍然比存储库中的方法少得多。