我有一个带有几个按钮的表单：添加，编辑，删除等。
我可以直接在add_click，edit_click，delete_click中实现添加，编辑和删除逻辑：直接在这些函数中更新数据库中的数据。
我也可以在workItem.Commands[CommandNames.Add].Execute();中使用add_click，并在以下位置处理：
[CommandHandler(CommandNames.Add)]
public void OnAdd(object sender, object target)
使用Microsoft.Practices.CompositeUI.Commands和CommandHandler的好处是什么？在哪种情况下我应该使用它？这是Microsoft一般命令模式的实现吗？谢谢！
答案 0 :(得分：0)
我认为我可以在这里总结一些好处，它们都与更好的关注点分离有关，并且在类似MVVM的场景中看起来很清晰。 为了清楚你可以做同样的事情，但我开始强迫自己使用Command迫使自己以“干净”和“理论上正确”的方式写作，以便习惯它。
这就是说，View和Code / Logic与Command方法的分离很好，因为：
最好重用：你可以重用UI对象或命令逻辑而不考虑其他部分;在按钮的情况下，你基本上避免在按钮本身中写入逻辑，如果你从按钮改为（例子）一个你根本不会触及逻辑的手势
它更适合维护：在编写事件处理程序时关注事件参数但是当您切换到另一个控件或另一个事件时，您可能已经非常依赖于事件参数，例如因为其他控件/事件不支持相同的参数。因此代码只在一个地方，可以轻松共享（和维护），这使开发人员可以编写更好的代码。对于共享开发团队（这是一个“现场”提示），每次开发人员在事件处理程序中添加一些代码行时都很容易，如果它有效但没有问题，但是如果他们必须编辑共享命令块则没有问题他们必须以更负责任的方式完成代码。
对于测试自动化更好：特别是对于共享代码块和分离测试团队; UI团队将编写代码来测试View，如果它重新编辑View，则他不需要再次链接到事件。
在大中型项目中以及随着时间的推移，一些好处是显而易见的，但是通过Command方法，您可以熟悉模式和更清晰的编码风格，您将习惯于更正确的开发方式。
附加：关于这个论点的其他有趣的观点是here