Is EE an MVC System?
Development and Programming
Hi,
CodeIgniter is the most beautiful source code I have worked with. One of its main features is its Model–view–controller (MVC) architecture.
The puzzler is, is EE an MVC system? I think not. Templates combine controllers, model access, and views into the same file, sort of smashing against the MVC structure of CodeIgniter.
I am curious about the deep thought and philosophy that went into making EE a non-MVC application built with CodeIgniter. Why doesn’t EE use MVC in its system for delivering to the front end?
It drives me nuts not being able to keep up with all the latest application of advanced software engineering and smartTalk, which CI and EE clearly are. I need to understand the rationale for EE architecture not following MVC, because CI’s MVC structure is supposed to be a big deal. I am like, wtf? If it is such a big deal, why not use it for EE? Or, if it’s used for EE, how?
Thanks, Dan
No, EE isn’t MVC. It’s a CMS, not a application development framework and it’s architecture actually pre-dates CI (EE1 was not built on CodeIgniter, but rather CI was birthed by removing a few rib bones from EE1).
I’m not sure you’ll get the deeper, philosophical rational behind it’s architecture from posting the question here in the forums as the people responsible for it don’t spend much time here these days.
CORRECTED: Hi Mike, thank you for confirming that EE is not MVC and the rest of your comment.
To me, EE is awesomely sensible as a cms. Extremely interesting that CI was born out of EE.
This is one of those situations where the more I find out, the more I find out I have no clue. 😊
Thank you for the info, very much appreciated.
Dan
Well I’ve read it, so maybe some brief lunch-time philosophy.
The foremost thing to keep in mind is that design patterns are not laws. They’re templates of what has been proven to work well for specific problems. Some people like treating everything as a design pattern problem and design their entire system from that perspective, but if you’re not careful you end up with something incredibly over-engineered (good example from the java world). MVC is nice, but there are lots of ways to skin that cat. The important part is getting a good level of separation.
We want software that is usable by non-developers. It’s the reason we don’t have explicit for-loops in EE’s templating language even though that would correctly describe what most tag pairs do. So we don’t usually start with architecture. We approach it with the experience first. In fact, the initial iterations of code don’t always resemble something a computer scientist would be terribly proud of. They’re exploratory steps to make things work and get a feel for the feature. Developers will naturally go for the solutions they know, which is why design patterns are taught to cs students. It just becomes a matter of recognizing that you’re headed for one. Sometimes that involves scraping most of the work and reimplementing it. Sometimes it means building something that doesn’t have a strict cs definition.
Now to answer your question. Strictly seen CI is probably closer to model-view-presenter than model-view-controller. Overall it’s a loose implementation, it’s up to the developer to truly enforce the separation. EE’s backend is where we most benefit from CI, although it has a ways to go in terms of strictness due to the evolution of the system. If you really wanted to push the definition you could say that on the frontend a template itself is simply a collection of controller names surrounding views (tag pairs). So each module’s mod.* file is a controller, each template tag pair defines a view, and modules can already have their own models so we’re all set. HMVC in a designer-friendly way.
That is how the architecture plays out, but we don’t always treat it that way. Separating concerns is important, but getting the user experience right is much more important than CS ego.