I am working on a Rails application which employs a classic MVC as its fundamental structure. In that structure the controller is supposed to be responsible for "which view to render when".
Now after reading a design pattern book I learned about design patterns and, inspired, started looking for ways to use them to improve the code quality. A couple of months ago I started writing code which renders a collection of books (not really, I'm just simplifying here). Each book is a ruby class instance, and has a 'type' property. Depending on the type property, books look drastically different from one another (whole different view partials are used for different books). Now I had a choice of having something like an
if statement in my controller or view, choosing what partial to render for each book, or to associate a partial with the book type property directly (which is more like a strategy pattern, I think). The second way seemed much better as it got rid of all if statements, so that's what I went for. I simply did something like
render books in the view and each book rendered correctly based on type.
All seemed beautiful, however. Now I started thinking whether this is against mvc model. The way the code is written now, the controller is not deciding anything about how to render a particular book. Confirming my fear of potential weirdness, the designers I work with brought up to my attention that they usually only look at the rails 'views' layer (they are responsible for writing html structure). Before they could easily follow what partial was rendered for each book, as before all logic was in the view in a form of easily read
if statements. Now to find out which partial renders for which type of book they have to go all the way into the model layer. Feels wrong to have them go there.
Did I do the wrong thing by putting the 'which partial to render' logic into the model?