Trongate Docs
switch to dark modeswitch to dark mode
The Problem With MVC

The Problem With MVC

The business of how best to structure any kind of computer application is as old as computing itself!  At the time of writing, the MVC design pattern is dominant among the PHP community.  Trongate brings a brand new design pattern to the table called HAVC.  This unique architecture has been designed specifically for developers who wish to make large scale, scalable and performant web apps.

In order to fully appreciate what HAVC gives us, it's worth taking a few moments to remind ourselves of the problems that MVC is attempting to solve.

A Super Quicker Refresher on MVC

The primary objective of the MVC design pattern is to achieve separation of concerns.  Broadly speaking this means that applications should be separated, architecturally speaking, into three distinct parts:

  • ​A model (file or folder) containing code that is dedicated to handling data.
  • controller (file or folder) containing code for dealing with business logic
  • view (file or folder) containing assets that are to be presented to the user

In the case of a PHP web application this typically means:

  • A folder or file containing code for interacting with a database
  • A folder containing PHP files for handling business logic
  • A folder containing HTML code that is to be displayed to the end-user

Did You Know?
Although the origins of the MVC design pattern date back to the 1970s, the pattern did not become popularized until the early nineties, when Steve Jobs and his team implemented MVC to build their NeXTSTEP ecosystem.  The work carried out by Steve Jobs and his team is widely regarded as being excellent and elements of NeXTSTEP are still being used in the latest version of Mac OS - even today!

So what could go possibly wrong?

Well, this requires a little explaining.  To be clear, the MVC pattern is actually rather good!  It does give developers a distinct separation of concerns.  That's good for productivity and upgrades.  However, in recent years, two problems with MVC have emerged - neither of which would have been applicable in the days of Steve Jobs and the NeXTSTEP team:

PROBLEM 1: Portability

Having your code separated into three distinct 'MVC' folders produces an enormous technical challenge when you're trying to take code from one app and add it to another.  Instead of copying and pasting one folder, you have to dig around in three different folders and carefully 'fish out' the assets that are to be transferred across.  

PROBLEM 2: Modern Web Apps Are Complicated

Modern web apps cannot be so easily broken into the three categories of i) model, ii) view and iii) controller.  Modern web apps often have API managers, settings files (sometimes stored as JSON or YAML), third party authorisation, media files, third-party JavaScript libraries, analytics code and much more.  Many of the assets that modern web apps have do not clearly fall into either the 'M', the 'V' or the 'C'.

In short, we need a better design pattern.

What HAVC Gives Us

The HAVC design pattern lets us hold on to the beautiful separation of concerns that we get from MVC.  However, HAVC architecture allows us to have clusters of self-contained modules - each of which can contain:

  • Controllers (i.e., PHP files with business logic)
  • Views (i.e., presentation code - usually in the form of HTML)
  • Assets (anything you like!)

The result?  A robust architecture that delivers class leading benchmarks and is also perfect for large scale web apps.  Since the modules are self-contained is means that moving features from one app to another is easy.  

Thanks to HAVC, Trongate developers can easily share code without having to go through any third party, privately owned websites (like Packagist).  As a matter of fact, the Trongate framework even has a module import wizard to make the process as easy as possible!  More about that later.


If you have a question or a comment relating to anything you've see here, please goto the Help Bar.