如果我需要能夠處理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中的附件，您將如何設計消息傳遞功能？

回答

相關問題