设计问题 - 使用事件，属性还是不是？ （mvc）

Question

我想知道您对以下设计方案的看法。

我有一个'AgendaController'（.NET MVC项目），它处理用户操作，如查看他们的议程，约会等等。当用户进行预约时，约会被保存在数据库中。然后，必须完成一项“次要”任务，在这种情况下，向用户发送消息（无论是短信，电子邮件还是其他不相关的内容）。我可以用三种不同的方式实现这一点：

1. 我可以简单地在控制器动作直接添加一个电话，像messageService.SendNewAppointmentMessage(data)。我想，这很好，虽然它确实让控制器的操作变得混乱了一点。具体来说，如果由于某些未来的需求需要做某些其他操作（例如，日志记录虽然不是一个好例子），但我还是会再次调用某个记录器类。

2. 我可以在AgendaController中声明一个静态事件OnAppointmentMade，并创建订阅此事件的MessageService。然后，当约会被保存时，事件被触发，并且实际的消息发送被处理在别的地方。如果这些要求出现，我可以有更多的课程订阅这个活动。这样，控制器动作保持非常干净，所有的“次要任务”都在其他地方执行。

3. 我可以在控制器动作[SendNewAppointment]上使用自定义属性，并在该属性的OnActionExecuting方法中发送消息。这很好地遵循MVC设计我猜，但我不一定喜欢属性混乱：我会有一个Authorize,AcceptVerbs,ActionName,SendNewAppointment等etc属性在一个单一的控制器操作。

哪个设计是首选？哪一个肯定是不行？我对第二个设计略有偏好，但我不知道是否应该（事实上）使用这个事件。我真的很想听听你的意见！

Answer 1

就我个人而言，我稍微优先考虑第一个选项，因为它是最可测试的选项。

第二个选项也很好，但我不喜欢静态事件的想法，因为静态的一切都很难测试（我不是说不可能，只是更难）。

Udi Dahan最近发布了一篇关于Domain Events的文章，它类似于你的第二个选项，他很聪明，所以值得考虑。就个人而言，我仍然倾向于将事件经纪人（本质上是调解员）作为实例传入的变体，但总的想法依然存在。