如果我需要能够处理ASP.NET MVC中的附件，您将如何设计消息传递功能？

我正在使用ASP.NET MVC网站，我的部分要求是用户能够互相发送消息。如果我需要能够处理ASP.NET MVC中的附件，您将如何设计消息传递功能？

从表面上看，这不是一项艰巨的任务。消息以其最简化的形式仅仅是一个“消息”表，其中包括诸如“SenderID，ReceiversID（FK），主题，消息”等内容。

但是，您将如何处理“附件”？用户可以浏览我们网站上的包含财务信息的机密PDF文件，并且他们可以点击“发送报告到”按钮将报告发送给其他用户以及文本消息。

同样，他们将能够上传多个文件，并将它们与他们的消息一起发送（而不仅仅是他们可以浏览的内部文档）。

你将如何在ASP.NET MVC中处理这个问题？

我考虑过有附件文件夹和附件表，所以如果用户点击“发送报告到”或上传文件，该文件被复制到附件文件夹，并在附件表中创建一个条目。

然后，如果用户点击具有类似/ messaging/attachments/{fileID}之类的路线的链接，它将向其发送适当的文件。我甚至可以维护附件/文件表中每个文件的校验和，所以如果用户发送相同的报告，我们将不会复制附件文件夹中的文件。

在某种程度上，我觉得我正在重新发明电子邮件，但客户坚持认为，为了保持安全合规性，我们不能简单地将这些报告通过电子邮件发送给我们的用户，他们必须登录我们的系统才能检索他们。

这是正确的方式去这样的事情，或者我应该看看不同的方法？

来源

2009-12-08 KingNestor

这基本上是我该怎么做的。 – 2009-12-08 21:16:04

想法似乎没问题。如果您使用SQL Server 2008，则可以考虑使用FILESTREAM。它使访问文件更容易。 – LukLed 2009-12-08 21:53:20

这就是我也会这么做的......只要你没有，考虑使用GUID作为fileID的含义 - 这只是另一层安全性（通过默默无闻）。这是我经常使用的（注意使用GUID而不是int的额外开销）。 – 2009-12-09 02:26:55

我完全不确定您的要求，但您可以考虑使用CMS系统或共享点。那些将拥有内置文档管理和消息内容所需的机制。即使您的应用程序是独立的，您仍然可以将它与SharePoint作为后端集成，以将大部分复杂性转移到它。

在大多数情况下，您在这里重新发明了轮子......而且这是一个非常大的轮子。尽量不要跑过来:)

来源

2009-12-08 21:36:05

我不同意轮子的大小 - 在有限的环境中，不必担心遵守标准是一个相当直接的问题。 – Murph 2009-12-09 09:35:29

根据问题中的信息，这可能不是简单情况之一。 KingNestor正在谈论多个附件，一些来自本地客户端的远程存储。他正在谈论上传，转发他们，处理安全问题，减少文件重复。等等。这是一个非常好的领域，但它不是一个微不足道的。这些功能需要花费很多时间才能开发和正确使用。由于它是一个良好的领域，现在有许多现有的解决方案可以用来代替滚动你自己的。 – 2009-12-09 17:53:45

如果我需要能够处理ASP.NET MVC中的附件，您将如何设计消息传递功能？

回答

相关问题