史磊's Blog

在一般的企业级应用中，Message是一个很常见的应用，其主要目的是可以让系统内的用户（包括系统用户）可以交流（包括attachment）。

如何去设计一个Message  BE(Business Model)模型？

首先会想到一种简单的做法：

class Message
	attr_accessor(:subject, :content, :readDate,:sender,:isReaded,:recipients,:attachments)
end

这种做法的好处就是简单明了，将所有信息全部都放在了Message 上,检索数据的SQL语句也会写的比较简单。但是这样的设计在系统使用一段时间就会发现系统的performance越来越差！究其原因，是因为每条Message在发出去时都会复制给所有的recipients，造成Message entity膨胀过快，导致performance 降低。

那我们改进的方法就是要避免message的过度增长，分析上面的模型，我们发现如果将isReaded、readDate和recipients抽成一个新entity,似乎就可以避免Message的复制。如下图示：

其中Recipient 中存储消息的接收人，这样在s1发送一条消息M发给r1,r2.r3时，只会产生如下Entity:

 One Sender,

 One Message,

Three Recipient

(其他entity可以暂时忽略掉)

如果sender或者recipient 要删除自己的message时，只需要将自身相应的IsDeleted设置为true即可（想想为什么不能直接删除entity?:）

模型的主要设计思路到此为止。

关于当前项目中出现的一些特殊需求，比如：

Kayla给自己的tax contact发的消息应该自动被kayla所属client的所有tax contacts共享。

这个其实只需要在发送邮件时自动bcc给其他tax contacts 就OK了。