David's Tech Blog

The flip side of what I said in my last post about Models in frameworks is that models shouldn’t know anything about the controller or view.  The data that the model is providing might eventually end up in JSON, or XML, or in a web page or HTML snippet, or in a CSV file.  None of that should matter to the model.

Generally models should not return error messages or “no data” messages that are intended for the eventual user, unless they are generic enough to be meaningful regardless of context.  It should always be obvious for the controller whether the call was successful, but the controller and view should handle how to display or send any messages.  Typically errors and other similar messages should be communicated through a central error or messaging handler.  The messages formatting and even content will vary quite a bit depending on how the results will eventually be delivered.

The data might be destined for a javascript heavy table, or for a CSV or Excel file, or a PDF file, or for a clean display on a light HTML page, or to pre-fill a form on a user’s return visit.  All of these will have very different formatting requirements, both for the data and for any messages that might get displayed to the user.  The deliveries that download files might actually never download anything if there’s no data, and might display messages in some other way.

Not building clean models, either by requiring that the controller know too much about the model, or by embedding information about the eventual delivery of the information in the model, is a recipe for spending time rewriting later, or for ending up with lots of duplicate code.