It's not necessary, in the sense that you can make it work. But your approach is somewhat... awkward.
In your approach, the pre-render and post-render work (such as clearing the appropriate render targets, and then presenting the final frame the screen) has to be done before and after
After all, that work has to happen at some point and your only other approach here is to track whether or not you've started it yet and then make the views that happen to be the first and last to draw make the appropriate calls. This is ugly.
So ultimately in this approach you have one giant conflated frame that includes both input processing, logic updates, and render commands in an unstructured order. This is both hard to follow, hard to profile, and potentially extremely problematic as the complexity of your rendering increases (for example, if you don't have an order-independent transparency implementation you have to sort transparent things back-to-front and make sure they render in that order to get correct transparency; how is that bulk operation done in response to individual model updates?).
It also raises some serious questions about the viability of the approach under concurrency scenarios.
I wouldn't advise this approach at all. If you really want to adhere that closely to the MVC pattern, I'd make the "rendering" that your views do in response to model updates simply be the preparation of any bookkeeping that needs to eventually be consumed by the renderer when you later call
render(). Things like making sure any visually-impacting properties that changes (like a unit going to a "critical health" state) are reflected in the data the renderer will eventually consume (like the "tint" color for that particular unit's shader).