XML literals undermine the MVC paradigm?

  • Article

Daniel Cazzulino has a very thought provoking post XLinq: is XML embedded in a host language a good idea or a terrible one?

 I believe Microsoft should strive not to provide another technology that could potentially bring back the nightmares we lived with ASP in the past. If it can be missused, it *will* be missused.

If it were for me, I’d limit the features available on the control code snippets to just control and rendering code: if..else, for/while loops, value retrieval (<#= foo.ToString #>), and that’s it. No object creation, no method calls (as they could have side-effects).

In some other correspondence with us, he points to a paper by Terence Parr, creator of ANTLR and StringTemplate:  https://www.cs.usfca.edu/%7Eparrt/papers/mvc.templates.pdf

I can definitely assure kzu that this has had the intended effect of starting some discussion!  I don't think that discussion has led us to fully agree with his position, but it has definitely helped us understand some of the issues more deeply. 

A few points that are clearer to several of us after these discussions:

  • XML literals are just syntactic sugar for generating constructors. To really ban the bad design pattern of entangling variable display information with more constant application logic, we'd have to ban string literals too. (Someone makes a similar point in a comment to kzu's blog).
  • Even if making it harder to tangle up display and application logic is the Right Thing to do, do our customers really want us to be Nanny McSoft?
  • Our new colleague Mark Shields brought up a good point - XML is not just for View anymore - it can be used appropriately in the data/model layer as a convenient representation of a node-labeled tree for all sorts of purposes.
  • There are numerous pragmatic reasons for intermingling display and business logic in the messy real world. It takes a lot of design talent, experience, and trial-and-error to find exactly the right abstractions that UIs can display independently from the application logic, and the application logic can manipulate independently of the display.  It's great that the industry is moving in the direction of separating them, but it's not at all clear that we're ready to enforce the separation.

We'd definitely appreciate others' thoughts on this topic.  How can we find the right balance in XLinq / VB9 between making XML much easier for non-specialists to work with yet not make it too easy for them to do the Wrong Thing?

Mike Champion