How would you design messaging functionality if I need to be able to handle attachment in ASP.NET MVC?

Question

I'm working on an ASP.NET MVC site and part of my requirements are that users are able to message eachother.

On the surface this isn't that hard of a task. Messaging in its most simplified form is simply a "Messages" table with things like, "SenderID, ReceiversID(FK), Subject, Message", etc.

However, how would you handle "attachments"? Users can browse through confidential PDFs on our website containing financial information and they are suppose to be able to click a "Send Report To" button to send the report to some other user, along with a textual message.

Similarly, they would be able to upload multiple files, and send them along with their message (not just the internal documents they can browse).

How would you handle this in ASP.NET MVC?

I've considered having an attachments folder somewhere and an attachments table, so if a user clicks "Send report to" or uploads a document, that file is copied to the attachments folder and an entry is created in the Attachments table.

Then, if a user clicks on a link that has a route like /messaging/attachments/{fileID}, it will send out the appropriate file to them. I could even maintain a checksum of each file in the attachments/files table so if a user sends the same report we won't be duplicating the file in the attachments folder.

In some way feel like I'm re-inventing email but the client insists that in order to maintain security compliancy we can't simply email out these reports to our users, they must log into our system in order to retrieve them.

Is this the right way to go about something like this or should I look at a different approach?

Answer 1

I'm not sure of your requirements exactly, but you might consider using a CMS system or sharepoint. Those will have the mechanics you need for both the document management and messaging stuff built in. Even if your app is separate you can still integrate it with sharepoint as a back-end to offload the bulk of the complexity to it.

In most ways, you are re-inventing the wheel here... and it is a really BIG wheel. Try not to get run over :)