I have a similar scenario in a project I have worked on where we had to check on every page for something similar to your messages. I put the logic into the relevant model (e.g. Message model for messages), and called a function from that model (which would gather and sort the data) from the beforeFilter, which would then set it to the view to be accessible anywhere.
I haven't found anywhere outside of this scenario where I've needed it to be used anywhere else as this data can then be accessed from the view (because beforeFilter sets it) and from any controller (because it's a model) that uses that model.
With regards to your question about whether it should belong to a User or a Message, it boils down (to me) that it is a message, so the logic for getting messages should belong to the Message model. Of course, your User presumably hasMany Messages, so you would give those two models that association, and could create a wrapper function in your User model which would get the data from Message, or rely on the model associations to get that data without the need to make a custom query.
Example:
- User model hasMany Messages
- beforeFilter of AppController or relevant controllers calls something like
$this->User->getMessages($user_id);
or$this->Messages->getByUserID($user_id)
; - beforeFilter sets the variable to be accessible in the view
Now all views can access the messages, and of course, you can call that function manually from another action whenever.
Problems may occur if you decide you need to access that data from another model. Workarounds include a temporary association to the Message model without a foreign key so you can query it as you would in a controller, but true MVC structure would probably suggest that the message data would be passed in to the other model's function.