为什么要使用用户命令和命令处理程序？
我有一个带有几个按钮的表单：添加、编辑、删除等。 我可以直接在add_click、edit_click、delete_click中实现添加、编辑和删除逻辑：直接在这些函数中更新数据库中的数据。 我还可以在 add_click 中使用 workItem.Commands[CommandNames.Add].Execute(); ，并在以下位置处理它：
[CommandHandler(CommandNames.Add)]
public void OnAdd(object sender, object target)
What is the benifit to use the Microsoft .Practices.CompositeUI.Commands 和 CommandHandler？在什么情况下我应该使用这个？这是微软通用命令模式的实现吗？谢谢！
I have a form with several buttons: add, edit, delete etc.
I can implement the add, edit and delete logic in add_click, edit_click, delete_click directly: update data in database directly in those functions.
I can also use workItem.Commands[CommandNames.Add].Execute(); in add_click, and handle it in:
[CommandHandler(CommandNames.Add)]
public void OnAdd(object sender, object target)
What is the benifit to use the Microsoft.Practices.CompositeUI.Commands and CommandHandler? In which case I should use this? Is this the Microsoft implementation of general command pattern? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想我可以在这里总结一些好处，它们都与更好的关注点分离相关，并且看起来很清晰，尤其是在类似 MVVM 的场景中。
需要明确的是，你可以做同样的事情，但我开始强迫自己使用 Command 来强迫自己以“干净”和“理论上正确”的方式编写，以习惯它。
这就是说，使用命令方法将视图和代码/逻辑分离是很好的，因为：
它更适合重用：您可以重用 UI 对象或命令逻辑，而无需考虑其他部分；如果是按钮，您基本上可以避免在按钮本身中编写逻辑，如果您从按钮更改为（例如）手势，您根本不会触及逻辑
，
这更有利于维护：您专注于事件参数当编写事件处理程序时，但是当您切换到另一个控件或另一个事件时，您可能会变得非常依赖于事件参数，例如因为其他控件/事件不支持相同的参数。因此，代码仅位于一个位置，并且可以轻松共享（和维护），这使开发人员可以编写更好的代码。对于共享开发团队（这是“现场”提示），每次开发人员在事件处理程序中添加一些代码行时，如果它有效，那么很容易就没有问题，但如果他们必须编辑共享命令块他们必须以更负责任的方式编写代码。
这对于测试自动化来说更好：特别是对于共享代码块和测试团队的分离； UI 团队将编写代码来测试视图，如果重新设计视图，他不需要再次链接到事件。
在中型大型项目中，随着时间的推移，一些好处是显而易见的，但是通过命令方法，您会熟悉模式和更清晰的编码风格，您会习惯更正确的开发方式。
另外：关于这个论点的其他有趣的点是 此处
I think I can summarize some benefits here, they're all related to a better Separation of Concerns and appear clears especially in MVVM-like scenarios.
Just to be clear you can do the sames things but I started to force myself using Command to force myself to write in a "clean" and "theoretically correct" way, to get used to it.
This said, separation of View and Code/Logic with Command approach is good because:
it's better for reuse: you can reuse UI object or the command logic without think to the other part; in case of a button, you basically avoid to write logic in the button itself, if you change from button to (example) a gesture you'll not touch the logic at all
it's better for maintenance: you focus on event arguments when write the event handler but when you switch to another control or another event you might have become very dependent on the event arguments, for example because the other control/event doesn't support the same arguments. Thus the code is just in a single place and can be shared easily (and the maintened), this brings developer to write better code. In case of shared dev teams (this is a "on field" tip) it's easy that every time a developer add some lines of code in a event handler, no problems about this if it works but if they have to edit a shared command block of code they have to do it in a more responsible way.
it's better for test automation: especially for shared blocks of code and for separation of testing teams; the UI team will write code to test the View and if it redesing the View he doesn't need to to link again to the events.
Some benefits are clear in medium-big projects and over time, but with the Command approach you become familiar with patterns and cleaner coding style, you get used to a more correct way to develop.
ADDITION: other interesting points about this argument are here