免责声明：由于还没有很好的答案，我决定发表一篇我不久前读的很棒的博客文章的一部分，几乎逐字抄写。您可以在此处找到完整的博客文章。所以这里是：
我们可以定义以下两个接口：
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代码时，该接口为我们提供了编译时支持。当我们改为（通过实现）将FindUsersBySearchTextQueryreturn 更改为return时，将无法编译，因为的通用类型约束将无法映射至。UserInfo[]IQuery<UserInfo[]>UserControllerIQueryHandler<TQuery, TResult>FindUsersBySearchTextQueryUser[]
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重命名该方法或获取其他参数，否则此调用将永远不会失败，并且如果您愿意的话，为此类编写单元测试非常容易。使用反射会稍有下降，但不必担心。
要回答您的问题之一：
因此，我正在寻找替代方案来封装整个查询，但仍具有足够的灵活性，以至于您不只是将意粉存储库换成大量的命令类。
使用此设计的结果是系统中将有很多小型类，但是拥有许多小型/集中型类（具有清晰的名称）是一件好事。与在存储库中对同一方法使用多个具有不同参数的重载相比，这种方法显然要好得多，因为您可以将这些重载分组在一个查询类中。因此，您获得的查询类仍然比存储库中的方法少得多。