S
scott.w.white
Looking at different MVC frameworks from many langauges from PHP to
Python, I've concluded that the explosion of MVC frameworks is mainly
due to undisciplined & unexperienced programmers.
Nobody would argue about the separation of the layers because this is
not the problem I have with it, if anything most implementations
emphasis separation at the wrong places. The end solutions end up
looking very mickey mouse.
It's been long asserted starting with Smalltalk there there be a
separation of layers with an application starting with the view (what
the user sees), the controller (which controls the flow of the
application) and the model (the representation of the data).
What MVC does not emphasis is the separation of the data access layer,
one of the most important pieces of an application. So what is done
with this? For many the DAL is either encapsulated within the model
or some toolkit that generates the SQL for them, this may lead to
decreased overall security of a database and inefficient queries.
The catalyst for MVC frameworks on the web has been the slew of poorly
written applications mostly in PHP & Perl , this has driven many
programmers looking for control & consistency. However this need is
short sighted when people find a magical bullet MVC Framework, and do
not place emphasis on minimization & reusability of code. Therefore
you end up with the same paradigm as before, just crappy applications
separated out into pieces.
No doubt there should be separation of layers, but there also has to
be a real dialogue about programming as a discipline & science, not as
a craft of gluing popsicle sticks together.
There should be more discussion of architecture before a project
starts and more code reviews and discussions in project teams. Also
one off projects (putting one programming on an island giving them a
compiler/interpreter) is a great way to get a crappy application.
That being said, I presently don't use one, but I'm still holding out
for an MVC framework that works for me and provides me power,
flexibility and is well documented.
Python, I've concluded that the explosion of MVC frameworks is mainly
due to undisciplined & unexperienced programmers.
Nobody would argue about the separation of the layers because this is
not the problem I have with it, if anything most implementations
emphasis separation at the wrong places. The end solutions end up
looking very mickey mouse.
It's been long asserted starting with Smalltalk there there be a
separation of layers with an application starting with the view (what
the user sees), the controller (which controls the flow of the
application) and the model (the representation of the data).
What MVC does not emphasis is the separation of the data access layer,
one of the most important pieces of an application. So what is done
with this? For many the DAL is either encapsulated within the model
or some toolkit that generates the SQL for them, this may lead to
decreased overall security of a database and inefficient queries.
The catalyst for MVC frameworks on the web has been the slew of poorly
written applications mostly in PHP & Perl , this has driven many
programmers looking for control & consistency. However this need is
short sighted when people find a magical bullet MVC Framework, and do
not place emphasis on minimization & reusability of code. Therefore
you end up with the same paradigm as before, just crappy applications
separated out into pieces.
No doubt there should be separation of layers, but there also has to
be a real dialogue about programming as a discipline & science, not as
a craft of gluing popsicle sticks together.
There should be more discussion of architecture before a project
starts and more code reviews and discussions in project teams. Also
one off projects (putting one programming on an island giving them a
compiler/interpreter) is a great way to get a crappy application.
That being said, I presently don't use one, but I'm still holding out
for an MVC framework that works for me and provides me power,
flexibility and is well documented.
