There are a number of ideas to chew on in this 6 year old paper by Terence Parr: "Enforcing Strict Model-View Separation in Template Engines". Parr is one of the creators of the StringTemplate template engine, which is ".. as simple, consistent, and powerful as possible without sacrificing strict model-view separation".
One of the highlights is the list of 5 rules implied by strict separation. Parr introduces them like so:
Before formalizing my intuition, I kept a few simple rules and tests in mind to evaluate entanglement. Could I reuse this template with a completely different model? Could a designer understand this template? 1f it looks like a program, it probably is. If the template can modify the model, it’s part of the program. If order of execution is important, it’s part of the program. If the template has computations or logic dependent on model data, it’s part of the program. If types are important, the template is a program.
The idea behind a strict separation is to avoid programming in the view and merely apply templating. With the web forms view engine in ASP.NET MVC we can not only break all 5 of Parr's rules, we can crumple them up like tissue paper and light them on fire. Of course, we can also behave ourselves and follow the rules of separation- or at least all of the rules except the one stating "the view cannot make data type assumptions".
Most MVC developers I talk to prefer to use strongly-typed views. Strong typing gives us intellisense and compiler errors. But - is there a cost? Does strongly typing the view lead to a form of bad coupling between the view and the model? Does it make the view harder to change? Does it make the designer's job more difficult?
I can hear you saying "no". Is this because the rendering phase of the processing pipeline is nearly impossible to test? Would it change your mind if testing a view template was easy?
ActionResult result = controller.ChangePassword(); var output = result.ExecuteResult();
What do you think?
Comments
So, neither good nor evil, just a way of doing things. Actually, AJAX is close to the ideal approach.
Ideally, of course, the Type in the definition would be an interface or custom object that is rather specific to the assumptions you make in this view. To allow you lots of freedom in your controller to choose what objects to send to the view. i.e. you don't want to require some specific business object if all you are using is it's ToString method.
P.S. I didn't quite get where you were heading with the testing tangent.
The real challenge here is a good pipeline for processing partials in controller. We need these partials reusable, so their classes must keep all possible context dependencies.