“电子邮件”类是否属于模型或视图？答案

【问题标题】：Does an 'Email' class belong in model or view?“电子邮件”类是否属于模型或视图？
【发布时间】：2009-11-30 04:33:02
【问题描述】：

模型中有User类，需要发送密码提醒邮件。

还是我完全迷路了？ ;-)

感谢您能给我的任何帮助！

【问题讨论】：

【解决方案1】：

除非您正在构建消息传递系统，否则电子邮件宁愿成为一种资源，而不是核心域的一部分。您可以将它们视为任何其他类型的资源，例如数据库访问、日志记录等。

就我个人而言，我会将其抽象为 MessagingService，以避免与电子邮件的耦合过于紧密——这将允许您在未来通过其他渠道发送消息（如果相关）。控制器将需要一个注入的 MessagingService 并发送消息。

涉及用户对象的唯一原因是您需要来自用户的值来填充电子邮件的内容，但这基本上只是数据的转换。

【讨论】：

【解决方案2】：

如果你真的想把事情分解成 MVC...建立在 Mark Seemann 所说的基础之上。

MessageController -> 发送消息/电子邮件 MessageModel -> 存储消息/电子邮件的信息无需查看。

我只是将用户信息直接传递给 MessageModel。 MessageModel 没有理由直接传递给 User 对象。

【讨论】：

【解决方案3】：

在我看来，电子邮件属于框架的显示层，在 MVC 概念的情况下是视图。毕竟，电子邮件只是请求输出的另一个显示选项。

不应使用模型或控制器来创建或显示输出。这就是使用像 MVC 这样的设计模式的全部意义所在。

编辑澄清；控制器将触发“输出”的发送，视图将使用从模型收集的数据来编写和发送 - 无论是作为电子邮件、HTML 还是特定视图设计的其他任何内容。

【讨论】：

我就是这样做的。控制器创建一个 Message（它是一个 View），将它添加到一个 Messenger（它是一个外部库类，但如果需要的话将是一个控制器），然后在 Messenger 上调用 send()。所以控制器中没有显示逻辑，视图中也没有动作逻辑；正确的？除了它的一些数据由控制器馈送到消息之外，模型不会进入其中。你是这个意思吗？
是的，这听起来很对。虽然，MVC 概念将允许 View 直接与 Model 交互，而不是通过 Controller。通过让 Controller 充当 View 和 Model 之间的中介，您可以将其变成更像传统的第 3 层架构的东西。 （参见维基百科文章中的图表；http://en.wikipedia.org/wiki/Model-view-controller）

【解决方案4】：

我会说：

编辑：正如milesmeow 所说，创建一个用于消息传递的控制器以允许扩展是有意义的。也许您将来希望能够通过 Twitter、IM、SMS 或其他媒体发送通知。为未来而建设是值得的。

【讨论】：