在非MVC项目中使用MvcMailer
我有一个 Windows 服务，应该定期发送电子邮件。
在 Windows 服务项目旁边有一个 MVC 3 项目，它使用 MvcMailer 发送电子邮件（非常漂亮）。
我想使用相同的引擎为 Windows 服务发送电子邮件。
我该怎么做呢？
为此目的导入 MVC 二进制文件并创建一个控制器和新视图？它会起作用吗？
将其保存在数据库中并请求我的 Web 项目发送电子邮件可能不是最佳解决方案，因为该信息是查询的结果，并且太大而无法在请求中发送。
我看到的唯一的其他选择是简单地请求 Web 项目来完成所有工作，但这样将 Windows 服务放置在另一个服务中以节省站点应用程序资源是没有好处的。 你会怎么做？
I have a windows service that is supposed to send e-mails periodically.
Next to the windows service project there is an MVC 3 project that is sending e-mails with MvcMailer (beautifully).
I want to use the same engine to send e-mails for the windows service.
How should I do it?
Import the MVC binaries and create one controller and new views for this purpose? Will it work?
Saving it in the database and requesting my web project to send the e-mail might not be the best solution because the information is the result of a query and is too big to be sent in the request.
The only other option I see is to simply request the web project to do all the work but this way it wouldn't be beneficial to place the windows service in another service to save the site application resources.
How would you do it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
作为 MVC Mail 的替代方案，ActionMailer.NET 现在可以在 MVC 之外独立使用。
详细信息请参见
http://geeksharp.com/2011/07 /06/actionmailer-0-6-发布/
As an alternative to MVC Mail, ActionMailer.NET can now be used stand-alone outside of MVC.
The details are covered here
http://geeksharp.com/2011/07/06/actionmailer-0-6-released/
我认为从服务调用 mvc 邮件程序可能有点矫枉过正。如果 mvc 项目应该为所有其他解决方案公开发送电子邮件 API，那么构建 REST api 可能是有意义的。但是，如果您只是想将操作方法的功能带到Windows服务中，那么我会选择进程内功能组件。如果您可以将 mvcmailer 操作方法的逻辑重构到另一个程序集中，为什么不这样做，然后将该程序集作为依赖项包含在您的 Windows 服务解决方案中。
如果您可以提供邮件程序的总体用途以及它在 Web 场景中的使用方式，可能会帮助我们提供更好的架构。
I would argue that calling a mvc mailer from the service might be an overkill. If the mvc project is supposed to expose sending the email API for all of your other solutions, then building a REST api might make sense. However, if you just want to bring the functionality of the action method to the windows service, then i would choose an in-process functional component. If you can refactor the logic of the mvcmailer action method into another assembly why not just do that and then include that assemlby as a depedency in your windows service solution.
If you can provide the over all purpose of the mailer and how it's used in the web scenario, it may help us to provide a better architecture.
为什么您认为发送给 mvcmailer 我们的查询太大？如果您的邮件程序 MVC 项目已经在运行并通过静态 URL 公开，那么它将成为您的电子邮件服务，只需将其作为来自您的服务的 Web 请求进行调用即可。
您可以绕过请求中的大小限制，这不应该成为问题。
Why do you think the query to send to mvcmailer us too large? If you have the mailer MVC project already working and exposed via a restful URL, that becomes your email service and simply call it as a web request from your service.
You can get around size constraints in your request That shouldnt be an issue.