构建电子邮件发送服务
我有几个网络应用程序，它们都利用发送电子邮件，无论是通过联系表单，还是某种通知更新等。
我发现的问题是，实际上没有任何方法可以跟踪发送的电子邮件Web 应用程序，所以我想出了一个可能的解决方案：
这非常简单真正转发 - 我不想让每个 Web 应用程序自己发送电子邮件，而是希望通过创建中央电子邮件发送器服务来统一该流程。
简单来说，每个应用程序只需在数据库的“出站电子邮件”表中创建一行，其中包含“收件人”、“发件人”、“主题”、“内容”数据。
然后，电子邮件发送器服务（Win 服务）将从发件箱中选取电子邮件、发送它们，然后标记为已发送。
尽管我会在数据库中存储“基本电子邮件”信息（收件人、发件人、主题、内容），但我真正想做的是存储“MailMessage”对象本身，以便电子邮件发件人服务可以反序列化原始 MailMessage，因为这将允许任何应用程序完全自定义电子邮件。
以这种方式使用 MailMessage 对象有任何问题吗？
更新：另一个目标是存储已发送的电子邮件日志 - 这就是使用数据库的原因。
I have a couple of web applications which all utilize sending emails whether it be by contact form, or some kind of notification updates etc.
The problem I have found is that there isn't really any way to track the emails which are being sent from the web applications, so I've come up with a possible solution:
It's pretty straight forward really - instead of having each web application sending the emails themselves I would like to unify the process by creating a central Email Sender Service.
In basic terms, each application would just create a row in a 'Outbound Emails' table on the database with To,From,Subject,Content data.
The Email Sender Service (Win Service) would then pick the emails from the outbox, send them and then mark as sent.
Even though I would store 'basic email' information (to,from,subject,content) in the database, what I would really like to do is also store the 'MailMessage' object itself so that the Email Sender Service could then de-serialize the original MailMessage as this would allow any application to fully customize the email.
Are there any problems with using the MailMessage object in this way?
Update: Another objective, is to store a log of emails that have been sent - hence the reason for using a database.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
更好的架构是让应用程序调用发送电子邮件服务上的某种公共接口。然后，服务本身可以负责将发送记录到数据库中。
这种架构意味着数据库成为服务的内部，因此减少了应用程序之间的耦合（每个应用程序都知道相对较小的公共合约而不是数据库模式）。这也意味着，如果您确实发现在数据库中存储 MailMessage 对象存在问题，那么您可以更改存储方法，而无需更新所有客户端。
A far better architecture is to have the applications call some sort of public interface on the send email service. The service itself can then be responsible for recording send in a database.
This architecture means that the database becomes internal to the service and so reduces the coupling between your applications (each application knows about a relatively small public contract rather than a database schema). It also means that if you do find some problem with storing MailMessage objects in the database then you can change the storage method without updating all of your clients.
为什么要使用数据库？只需让应用程序直接调用您的电子邮件服务并提供所有信息即可。
如果您想要对发送进行排队，则可以使用与 WCF 的
net.msmq绑定，这会将请求存储在服务将从中读取的可靠队列中。所有这一切都会为你完成。Why use the database? Simply have the applications call your email service directly, providing all information.
If you'd like to queue up the sends, then you can use a
net.msmqbinding with WCF, which will store the requests in a reliable queue that the service would read from. All of this would be done for you.