Anybody speaks about the MVC pattern these days. When designing the Tine 2.0 application and api structure we also thought about implementing it with the standard MVC pattern.
While the clean 3-tier layout of the MVC pattern is crucial for business applications the MVC pattern brings some limitations we solved with small extensions to the pattern.
Single Page Application
Tine 2.0 is a so called ”’Single Page Application (SPA)”’. This means anything is served from a single URL, the index.php. If a login screen is shown or if a application does a complex transactional operation, it’s always handled by the index.php.
This layout simplifies the application flow dramatically, as there is no need to figure out the required controllers/actions by the url and there is no need to define rewrite rules. As a consequence we don’t use a traditional front controller and only have a light-way dispatcher in the index.php.
Service Orientated Architecture
Tine 2.0 has a service orientated architecture. The normal ”views” in MVC apps are perfectly sweetet for ”HTML output”. However the Tine 2.0 server returns almost no HTML, but is capable to serve the needed data in various representations. Moreover it also receives its actions and data also via various representations.
As a consequence Tine 2.0 applications normally don’t have view’s, but they have server classes, e.g a JSON class. This server classes handle all the input and output conversions from and to the the requested format, e.g. JSON.
Multi Back-end Capable
The Tine 2.0 application pattern is designed to support multiple back-ends. This means that the applications records store could be of totally different types. A simple example is the Address-book. It’s contacts can come from a SQL back-end or from a LDAP back-end.
In the standard MVC pattern the models do the persistence operations on a single persistence instance, which normally means they do all the SQL database handling. This does not fit the Tine 2.0 multi back-end requirement.
As a consequence the Tine 2.0 models are just simple data containers and have nothing to do with persistence. Controller store and get those simple models via the back-end classes which hide the complexity of the different physical back-ends by implementing a simple public interface.
Find out more about the Tine 2.0 application layout in our wiki.
I think most of the problems you got around are not really related to the MVC pattern itself, but rather to how a lot of so-called MVC frameworks for websites implement it.
Single Page Application: The pattern was not developed for websites at all, thus it should be quite irrelevant if your website uses a single index.php, a lot of other PHP files, or no PHP at all. As a consequence, using MVC or not is also not related to using a specific programming language or techniques to reach a specific Controller/Action such as rewrite rules.
Service Orientated Architecture: As noted above, MVC was not invented to dynamically create websites. In fact, also GUI applications can greatly benefit from a MVC approach.
). If MVC is implemented in a clean way, there is no real need to stick to just one view representation of the same output.
What you implemented sounds like a quite normal Model to me (keep in mind that I do not know Tine 2.0 or it’s source code
Multi Back-end Capable: This is, again, something which could be a typical requirement for a normal MVC application. Normally, the Controller should have no idea of where the data comes from – it just uses what it gets from the model. And the way this is implemented in the model is then related to the actual backend. Having POPO
which have no idea about any type of persistence or backend can also be crucial to stay dynamic. 
After all, just knowing Tine 2.0 from your blog post
, I think that your implementation of MVC is a pretty standard one, even though it differs from all those PHP frameworks you find on the internet in so far that it sounds better and more dynamic. 
Hi Hangy,
thx for your comment.
I should better have named my post: “To Zend_MVC or not…”
In fact I had some discussions with people who ask why we do _not_ use the standard Zend Framwork implementation of MVC.
And exactly as you said, what we at Tine 2.0 in MVC, but the Zend Framework interpretation of MVC didn’t fit.
cu
Cornelius