Supervising Controller, Passive View
10 things you didn't know about the Supervising Controller pattern
I've been spending time implementing some more RESTful features of
, and I've run into a side effect of using the Supervising Controller variety of the Model View Presenter pattern.
Lets just imagine for a moment (purely hypothetical of course) you've been soaking up some of
's hype around REST based development, and you're thinking - 'yeah, I'm gonna reuse my presenter' (/controller ... go on I dare you, explain the difference :) to display an (xml | json | atom)* [*delete as appropriate] representation of my data. Ok, I know most of you are nodding now - its the sort of thing you imagine every day!
Moving on swiftly...
So, lets say you already have an aspx (ie html) representation of a list of articles, and to produce this representation, you pass your view an IList<Article> which is then databound to a repeater control (don't tell me you used a GridView :).
If you now decide you want to represent this purely as xml while reusing your existing presenter, its worth realizing that your xml view logic now has to effectively recreate the databinding which your aspx view used. It isn't necessarily difficult, but you will be Repeating Yourself somewhat and you KNOW that's bad m'kay (DRY).
If you think you may need to extend your representations beyond html, it may be worth sticking to Passive View... but also remember - YAGNI !!!
Oh the choices... the choices (the horror... the horror)...
Dude, more acronyms, pls.
Heheh, sorry... making assumptions about prior knowledge :) YAGNI - "You Aint Gonna Need It" DRY - "Don't Repeat Yourself" REST - "Representational State Transfer"
Thanks for posting a comment
© 2007 Intrepid Noodle Ltd
Design and Development - Intrepid Noodle Ltd
Company Number: 0384 5300 | Registered Office: The Barn, Whitwell Grange, Durham, DH1 2SJ.