When people talk about Web Application Frameworks (WAF), they often refer to web frameworks with a model–view–controller (MVC) architecture. MVC is a software architecture pattern that separates the representation of information from the user’s interaction with it. Most popular frameworks actually follow the model–view–adapter (MVA) that decouples the model and the view as described below:
Traditional MVC arranges model (e.g., data structures and storage), view (e.g., user interface), and controller (e.g., business logic) in a triangle, with model, view, and controller as vertices, so that some information flows between the model and views outside of the controller’s direct control. The model–view–adapter solves this rather differently than the model–view–controller does by arranging model, adapter or mediating controller, and view linearly without any connections whatsoever directly between model and view. — Wikipedia
More and more frameworks consist of a set of components (e.g. Zend). This is why people start to talk about “full-stack” vs. “glue” frameworks. A “glue” framework allows the programmer to create a tailor-made framework by gluing the needed components together. Full-stack frameworks, on the other hand, do not require you to do this.
Others talk about the difference between “push-based” vs. “pull-based” frameworks. This difference essentially is whether the framework pushes data towards the view or pulls the data in from the view. Most frameworks use the “push” approach.
Separation of concerns
What everybody seems to agree is that we need some form of “separation of concerns” or a n-tier architectural model. This means that we “divide the system cleanly into three tiers: the presentation tier, the business-logic tier, and the data-access or resource tier”, like MVC or MVA does.
What many framework architects do not seem to optimize for are these three important things:
- Cost of learning – maximize documentation reuse & minimize innovation
- Cost of scaling – maximize compatibility & minimize lines of code executed
- Cost of defects – maximize best practices & minimize complexity
They seem obsessed with optimizing separation of concerns a.k.a. reducing the “Cost of spaghetti”. In their efforts they create hard to grasp concepts, like “Dependency Injection” and “Aspect-oriented programming“. Do not get me wrong: I am not saying that these methods do not help you to fight the cross-cutting concern, but IMHO the complexity problems they cause outweigh their benefits of keeping things organized.
MindaPHP to the rescue
So, it may be clear that I believe that simple is better. With that “vision” I wrote MindaPHP. Whether you like it or not you may decide for yourself, but it certainly is easy to learn and about 10-20 times faster than CakePHP or Symfony, while providing the same abstraction layers to keep things organized.
MindaPHP aims to be a full-stack framework that is:
- Easy to learn
- Secure by design
By design, it does:
- … have one variable scope for all layers.
- … require you to write SQL queries (no ORM).
- … use PHP as a templating language.
Mainly to make it easy to learn for PHP developers. Check it out!