One of the topics that periodically crops up in discussions as it relates to WordPress is the idea of WordPress and MVC.

That is, developers wants to take an MVC approach to building WordPress applications. And I get it – I love MVC. It’s why I used to work with Rails, it’s why I was really excited when Microsoft released .NET MVC years ago (when I was working in .NET).

But the thing is that MVC is not the silver bullet of web development that we try to make it out to be. Yes, it’s an awesome design pattern, and I personally think that it fits the web application model like a glove, but not every framework or platform implements that design pattern.

Case in point: WordPress is not MVC.

And that’s okay. I think we need to leave the desire of trying to shoehorn it into our projects aside especially when the pattern WordPress provides is not only sufficient, but works well when leveraged correctly.

“But I Love MVC!”

So do I! In fact, I spent the last year working on a project that more-or-less mimicked the MVC architecture.

A high-level example of MVC.

A high-level example of MVC.

For example:

  • Views were implemented using templates
  • Controllers were implemented by a combination of using function names like `create`, `read`, `update`, `destroy`, `delete`, and so on (even though these functions were hooked into the WordPress API
  • Models were functions also were called to validate and verify data prior to serializing the data. Again, this required that certain functions be hooked into WordPress to achieve the desired result.

Finally, a set of rewrite rules gave the application a clean set of predictable URLs in the format of /people/update/1 or /people/all.

What Pattern Does WordPress Implement?

WordPress implements the event-driven architecture (of which there are several variations such as the Observer Pattern).

In short, you can conceptually think of this as the following:

  • Things happen when WordPress is processing information.
  • You can register your own function to fire when these things happen.

Not too complicated, is it?

A high-level example of event-driven patterns

A high-level example of event-driven patterns

When you begin to think in terms of the paradigm in which it works rather than trying to make it work the way that you want it to work, it’s liberating. It helps to solve problems much more easily.

The bottom line is this: WordPress implements the event-driven design pattern, so even if you end up trying to implement MVC, you’re still going to have to utilize the hook system.

If you’re not careful, you can end up trying to craft the perfect architecture without actually getting your work done, and thus end up finding yourself so high up in the atmosphere of software that you’ve effectively become an architecture astronaut.

So You’re Saying Avoid Design Patterns?

Not at all! Design Patterns serve a purpose because, above all else, they basically give us solutions to previously and commonly solved problems. Use them!

But the point I’m trying to make is that we don’t need to try to force things to fit pattern just because we like the pattern. That’s not their purpose. Instead, leverage the primary pattern that your platform of choice implements – in our case, it’s an event-driven pattern – and then implement patterns where they fit (such as dependency injection or something like that).

Otherwise, it’s like trying to put your foot in a glove.