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.
