Archive for category Frameworks

One Man’s View is Another Man’s Data

I think it’s common for a developer to get the idea in his or her head that developing under an MVC (Model View Controller) paradigm is ultra cut and dry: There is one Model, one View, and one Controller for a given task. Within a given layer of the software stack this may often (or even always) be true.

However: all software produces something (in its view) which is consumed by the next higher tier of the software stack as data, and thus is only part of the model for that next stack. All software produces something to be consumed by something else. What is to you a view is to someone else data.

So it’s important to avoid thinking that there’s something special about your particular view (no matter where you are in the stack) – as if it’s somehow magical and the view. You’re never the end of the line, it doesn’t matter how far down the line you really are. The end of the line is the brain of the human who will ultimately consume this data. Even then they’re not the end of the line, they process that data, make decisions based on it, and produce some output of their own – whether it’s using it to produce new data for the next action within the application, taking that data elsewhere as an input to a different process, or storing it to memory for later use as data for a future process.

Let’s look at an example from web development. The PHP/ColdFusion/ASP.NET/Ruby/FOTM developers I know tend to think of themselves as the end of the line (and I have too to a substantial extent). They’re producing something to be consumed (as they see it) by the end user. This is the guy who gets to make the HCI (Human-Computer Interaction) interface that either creates a positive experience for the user, or a negative one. Everything past him just follows the instructions he produces. Bold this, outline that, send this data there. What’s harder to see is that he’s just following the instructions he was given by the user and producing data in a format that other software later in the stack requires of him.

What the web developer calls data is actually just a view provided by lower down in the stack (a database typically, which in turn gets a view of stuff from the filesystem which it calls data, etc). A web developer’s view (HTML typically) is just data to the web browser. The web browser’s view (graphical representation) is just data to the display driver. The display driver’s view (bits of light on a computer monitor) is just data to the user.

The software stack starts and ends with the user. If anything is sacrosanct, the ultimate MVC, it’s the user. But as I’ve already said, the user ends up just starting the cycle again, maybe she uses that data to feed the computer again, or maybe she uses that data for another purpose.

So don’t get caught up in “HTML is the view, XML/SOAP is data,” it’s all data to someone, and therefore it’s all a view to you. Don’t think there’s something special about one way to structure data vs another way to structure data. Finally don’t create different channels depending on what consumes your data. Use the same data channels (Model/Controller) and provide a different View. That is after all what the purpose of a View is all about – consumer agnosticism.

, , ,

No Comments