Ultimately, it’s like any directory structure. Let’s say my colleague is away for the day, and I need to find a vital piece of documentation on his machine. I log on, (and assuming I don’t know how to search) and I start trying to fathom his personal method for organising his disk space.
It’s the same with any application architecture. There is an underlying logic that takes some investment to grasp. The benefit of MVC is that, while it initially seems rather abstruse, it’s very logical - and in practice you find it much EASIER to locate a given file.
Let’s say I have a problem with the code at http://www.domain.com/foo/bar- well I already have some very good clues as to where the problem is. For starters, it’s in the “foo” controller, or whatever controller “foo” is mapped to - and possibly in the “bar” action of that controller. Now I know which file to load, I can quickly ascertain if the problem is in the controller, or in any business logic (the Model) that the controller or view is interacting with.
The advantage of MVC is twofold. The obvious one is separation of presentation and logic, but there is also the fact that if your company works with the same framework for a while, there’s a standard directory structure that everyone in the team adheres to, so you eliminates some of the idiosyncracies of the individual in organising your projects.
On the other hand, MVC is overkill for something small like a brochure site - and some frameworks can take the whole decoupling thing a bit far, leading to a resource hungry beast <ahem>Zend</ahem>
I actually downloaded those frameworks not so long ago to get a better idea of what MVC is. And I’ve got to say I came away with a very bad first impression. It was an utter mess. I can understand having set processes and a set structure for each of your projects but how is this sort of structure better than the tried and trusted basic structure.
i.e a few basic folders like:
/images/
/js/
/includes/
/css/
My impression of MVC so far is that it actually creates extra work especially for a developer who didn’t work on the project initially. I’ve had to fix bugs/issues in other products before that used this MVC structure and I literally spent over an hour searching for what should have been a 1 minute fix.
Surely though it also creates a barrier to maintainability? From my (admittedly brief) experiences with the three structures (whether MVC or not), it can make life hard for those who don’t understand it. i.e. if a different developer came into an MVC project. It creates a dependence on having someone with a more specialized skill. However like I said I will read up and hopefully do an MVC project down the line to get a better overall understanding of it. Who knows I may even end up advocating it’s usage lol. Just from an outside perspective it seems to create problems whilst solving other problems.
Well I’d argue the other way. At least with MVC you know the developer at least attempted to separate the various components and you should at least have an idea of where to look for something as it presents a (albeit very loose) standard With a custom architecture, there’s no clue as to where to find something so you would still need to trace through the code to find the bit you’re after. The answer, of course, is proper documentation
Pretty much all three. Fair enough if oscommerce isn’t even MVC though looking back the structure certainly seemed very familiar to the sort of structure I saw when I downloaded Cakephp and code igniter about a month or two ago. What would be a good example of a good (and well documented) MVC Framework? I certainly want to know more about them even if I remain unconvinced by how useful they are lol.
I guess it depends on the size of the application. The project I’m working on I would say is pretty large. Though I found it hard enough to convince the person I’m working with to use OOP for what is already going to be a rewrite of an old project lol.
Surely though it also creates a barrier to maintainability? From my (admittedly brief) experiences with the three structures (whether MVC or not), it can make life hard for those who don’t understand it. i.e. if a different developer came into an MVC project. It creates a dependence on having someone with a more specialized skill. However like I said I will read up and hopefully do an MVC project down the line to get a better overall understanding of it. Who knows I may even end up advocating it’s usage lol. Just from an outside perspective it seems to create problems whilst solving other problems.
Are you talking about codeigniter or cakephp or oscommerce? They are very different things and I don’t recall codeigniter or oscommerce being very MVC. It is difficult to take you comments about MVC seriously when you admit to not understand MVC and seem to be commenting on some specific code somewhere you didn’t like that may not be MVC.
For small sites a simple structure is quite maintainable. I think you mean “familiar” rather than “tried and trusted”. That scheme is tried and failed on larger applications.
No one said MVC is less work. The point if MVC is that the clear separations reduce problems/side-effects and improve maintainability – especially as applications get larger. MVC is a proven solution to some problems. Whether you have those problems and need MVC is a separate question.
