So anyway, I was trying to explain to someone the pitfalls of MVC, and how this design methodology for web development came to be popular, and finally how the modern implementations of MVC are really kinda different than what the inventor of MVC was really shooting for.
Lets start with a brief history:
First, there was HTML and the Mosaic browser to render it (and lynx for command line viewing). Ah, those were the days. It was all static and things were good.
Then somebody got the bright idea that, hey, wouldn't it be nice if we could include other HTML files into an HTML file, output a few interesting system variables like dates, and execute other programs passing their output along? Thus Server Side Includes were born. This evolved, and soon SSI had language contructs like if/then, etc. Much more advanced languages were invented using this style, like PHP and ASP. These "template" languages were designed to be "HTML with embeded code"
Of course, other options were to go the other way around and just run a program that generated HTML. Perl was a natural here. To make things easier, these languages created templating systems where HTML code files could be loaded, and special markers within them could be replaced by content generated by the code. This created a nice separation between the code and the presentation so that visual designers could work on the presentation without so much messing around with the code.
This separation was then emulated by all the other languages, even though they already were essentially implentations of template systems. Why? Because they didn't force this separation. So template libraries were designed that did force the separation.
At the same time, using a database to store your dynamic information and using code to format it into something presentable came into wide use. Now you've got a three tier system... data, code, and presentation.
MVC was a design pattern already in wide use for application development with standard GUI's. It was natural to apply this to web sites... the Model was the database, the View was the presentation, and the Controler was the code that tied it all together.
Instead of a procedural stream of commands to query the database, massage the data, and format it into HTML, you now have a trio of Objects talking to each other: Controler figures out what to do based on the url called, it asks the Model for some data, and then it tells the View to display it.
Now, in theory, you can have one guy design a kick-ass database and a Model to access it, while somebody else does the Controlers and your design guy can create the views (or at least the templates used by the view object).
Except that web applications are not the same as conventional desktop apps.
The first generations of MVC based web apps simply sent the resulting static HTML to the browser for display. Then some jerk had to invent a way to update portions of the HTML being displayed, using javascript, on the browser. And those finicky users wanted things to be faster, so they wanted things like form validation to happen in the browser, and they just loved the speed of only updating parts of the HTML instead of refreshing the whole page.
So now, on the browser, you have MVC again: the asynchronous data requests to the server (Model), the HTML which can be accessed through a series of objects (the View) and the javascript making it all happen (Controler). So now you have to implement parts of your application's Controlers in two places (the models and views on the browser side can be relatively dumb and just ask for stuff from the server). Like form validation - on the browser for speed and convenience, but also again on the server to prevent hackers from F'ing things up.
All of this is leading up to the fact that the modern MVC methodology is not exactly what its inventer had in mind in the first place.
Like a lot of those early computer pioneers, he was really looking at how can we make computers easier to use, and not necessarily how can we make them easier to program.
Originaly, the Model was not supposed to be some abstract mathematical construct that was designed to be efficient for a computer to store and index (ie, a relational database). It was supposed to be an intermediary between how a person thought of the data and how it actually needed to be stored. The View was supposed to be a user maleable canvas on which to inspect and modify that data. The Controler is largely the same, and just coordinated between views.
It may seem like a minor difference, but its actualy significant: the modern model is an attempt at an object oriented abstraction to a database. The original idea of a model was an attempt at an abstraction to a person's mental idea of the data. Instead of the database leading the way, it should be the human leading the way and the computer bending to his way of thinking.
I dont know exactly yet how to do it. But a new method needs to be developed that handles both problems -- making it easier to program, and making it easier for users to use.
In this fanciful system, you would write one bit of code that would generate resulting code to run on both the client and the server so you don't have to duplicate things. It would also let you easily model things the way people expect them to be and translate that into something efficient for the computer to handle internaly.
Instead of the current state of affairs, where the programmer is forced to write largely duplicated code in perhaps different languages to do the same thing over and over, and the user is forced to jump through unintuitive hoops while using the software - mainly because the programmer is too busy with grunt work to be bothered with making anything more than just barely usable (or very usable to him, or anyone with a brain like his, which is very few people)
No comments:
Post a Comment