上篇随笔讨论了CQRS中Command的一种基本实现。
面对UI中的各种命令，Controller会创建相应的Command对象，然后将其交给CommandBus，由CommandBus统一派发到相应的CommandExecutor中去执行，我们的ICommandBus的接口声明如下:
public interface ICommandBus
{
void Send<TCommand>(TCommand cmd) where TCommand : ICommand;
}
当在实际项目中应用CQRS时，我们会发现上面的做法存在一个问题：有时候我们希望Command在执行完后返回一些结果，但上面的Send方法返回void，也就意味着我们没有办法得到执行结果。我们以一个用户注册的例子来说明。
数据库中用户表(User)的定义为User (Id, Email, NickName, Password)，括号中的为字段，其中Id为varchar(36)的Guid字符串。
注册用户的RegisterCommand代码如下：
public class RegisterCommand : ICommand
{
public string Email { get; set; }public string NickName { get; set; }
public string Password { get; set; }
public string ConfirmPassword { get; set; }
public RegisterCommand()
{
}
}
假设在注册后需要将新注册用户的Id存到Session中，那Controller的实现就变得有点纠结：
[HttpPost]
public ActionResult Register(RegisterCommand command)
{
CommandBus.Send(command);Session["CurrentUserId"] = ???
return Redirect("/");
}
上面的???处要怎么写？我们无法直接得到新注册用户的Id，因为Id只有在Command执行时才会生成。
所以只能在CommandBus.Send(command)的下一行添加一个查询：
[HttpPost]
public ActionResult Register(RegisterCommand command)
{
CommandBus.Send(command);var newUserId = Query<User>().OrderByDescending(u => u.Id).Select(u => u.Id).First();
Session["CurrentUserId"] = newUserId;
return Redirect("/");
}
这样虽可以勉强解决问题，但比较繁琐，而且也无法保证在Send之后查询之前的这一小片时间里不会有其它新用户产生。于是，我们开始反思Command的设计......
这个方案也正是Sharp Architecture所采用的，即添加一个带两个泛型参数的ICommandExecutor<TCommand, TResult>接口，这样我们就有了两个ICommandExecutor接口：
public interface ICommandExecutor<TCommand>
where TCommand : ICommand
{
void Execute(TCommand cmd);
}// 这是新添加的带有两个泛型参数的接口
public interface ICommandExecutor<TCommand, TResult>
where TCommand : ICommand
{
// Execute方法返回值变成TResult
TResult Execute(TCommand cmd);
}
为了适应这种变化，我们也需要相应修改ICommandBus的接口：
public interface ICommandBus
{
void Send<TCommand>(TCommand cmd) where TCommand : ICommand;// 这个Send方法的返回值是TResult
TResult Send<TCommand, TResult>(TCommand cmd) where TCommand : ICommand;
}
看起来不错，现在对于注册用户的例子，我们只要调用第二个Send方法即可:
[HttpPost]
public ActionResult Register(RegisterCommand command)
{
var newUserId = CommandBus.Send<RegisterCommand, string>(command);Session["CurrentUserId"] = newUserId;
return Redirect("/");
}
但如果我们仔细看看，会发现这是一个非常糟糕的设计！Controller的开发人员怎么知道RegisterCommand执行完会返回结果？怎么知道返回的是string而不是int？Controller中可以写成CommandBus.Send(command)，也可以写成CommandBus.Send<RegisterCommand, int>(command)，也可以写成CommandBus.Send<RegisterCommand, string>(command)，同样是发送RegisterCommand命令，这三种调用全都可以编译通过，但是只有第三个才不会在运行时出现问题。
渐渐的，我们就会变成每调用一次CommandBus.Send()方法就要去查看对应的CommandExecutor是怎么实现的，这就让Command和CommandExecutor相分离的设计变得一点意义都没有。所以我们需要寻求其它的解决方案。
PS: Sharp Architecture中的ICommandHandler对应本文中的ICommandExecutor，ICommandProcessor对应本文中的ICommandBus，但我觉得它的ICommandProcessor的取名也太容易让人误解了，单从名字上看，谁能分清楚ICommandHandler和ICommandProcessor的区别？
其实这个方案非常简单：在Command对象中添加一个ExecutionResult的属性（这个属性要放在具体的Command类中，不要放于ICommand接口中）。如上面的用户注册的例子，我们可以添加一个RegisterCommandResult的类，然后将RegisterCommand改成如下所示：
public class RegisterCommand : ICommand
{
public string Email { get; set; }public string NickName { get; set; }
public string Password { get; set; }
public string ConfirmPassword { get; set; }
// 亮点在这里
public RegisterCommandResult ExecutionResult { get; set; }public RegisterCommand()
{
}
}// 亮点在这里
public class RegisterCommandResult
{
public string GeneratedUserId { get; set; }
}
在调用CommandBus.Send()之前，我们完全不用理会这个ExecutionResult属性，对于Controller的开发人员来说，他只要知道在Command执行完后，ExecutionResult的值就会被赋上，如果没有，那就是CommandExecutor的bug。
而我们的RegisterCommandExecutor就可以改成（User类的构造函数会调用Id = Guid.NewGuid().ToString()对自己的Id进行赋值）：
class RegisterCommandExecutor : ICommandExecutor<RegisterCommand>
{
public IRepository<User> _repository;public RegisterCommandExecutor(IRepository<User> repository)
{
_repository = repository;
}public void Execute(RegisterCommand cmd)
{
var service = new RegistrationService(_repository);
var user = service.Register(cmd.Email, cmd.NickName, cmd.Password);// 亮点在这里
cmd.ExecutionResult = new RegisterCommandResult
{
GeneratedUserId = user.Id
};
}
}
然后Controller就很简单了：
[HttpPost]
public ActionResult Register(RegisterCommand command)
{
CommandBus.Send(command);// 亮点在这里
Session["CurrentUserId"] = command.ExecutionResult.GeneratedUserId;return Redirect("/");
}
这个方案和第一个方案的关键区别就在于，RegisterCommand中定义的ExecutionResult属性可以让开发人员清楚的知道这个属性会在Command执行完后被赋上合适的值。对于一个Command，如果开发人员在其中找到类似ExecutionResult这样的属性，他就知道这个Command执行完后会返回执行结果，并且结果是以赋值的形式赋给Command中的ExecutionResult属性，若Command中没有发现ExecutionResult这样的属性，那开发人员便知道这个Command执行完不会返回执行结果。
PS: 因为本例中User.Id采用的是Guid字符串，它可以在创建User对象时立刻生成，所以下载中的代码可以跑得还不错，但如果User.Id是使用SQL Server的自增长int类型，那就跑不了了，因为UnitOfWork是在Command执行完后才Commit的，所以，要处理自增Id的情况，我们需要稍微修改相应代码，比如将IUnitOfWork实例作为参数传给ICommandExecutor.Execute()方法，并把IUnitOfWork的提交转交给CommandExecutor负责，然后在对RegisterCommand.ExecutionResult属性赋值前先调用IUnitOfWork.Commit()方法，这样便可以解决问题。
到目前为止，我们所讨论的Command都是同步执行的，如果Command被设计为异步执行，那本文所讨论的内容便可以直接忽略。
如果系统的性能可以满足需求，同步Command无疑是最好的。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。