Most complex plugins do that in one form or another. Unfortunately, many plugins start with a god class and don’t use a clean OOP approach. WooCommerce is a popular example.
Plugins cannot provide a real front controller, because they are loaded after WordPress has set up most of its environment. And all plugins are almost equal: If two plugins try to handle the same request, the first one wins probably. You never know which plugins might compete with yours.
For a very basic example see my plugin T5 Public Preview (from this answer).
- The front controller is the class T5_Public_Preview it loads the needed classes and creates the objects depending on the request (admin or front-end).
- There are three models:
- And two views handle the output:
T5_Render_Endpoint. The latter doesn’t actually show something, but it changes WordPress to show a different output in some cases.
OOP is about communication between objects and components. So the real problem is not the pattern, it is the communication. WordPress core is not OOP, everything is lumped together; the code was and is growing organically. Without a clear inner structure, WP solved the communication problem with actions and filters (hooks): predefined events, allowing any plugin to change or replace output and application logic.
Your plugin has to operate within this given structure. There are some interesting communication problems to solve:
These are the most important responsibilities for a plugin front controller. You can delegate some to subsequent controllers, but the front controller has to know how they work. In my opinion, a front controller in a WP plugin has to know too much too often. But I’m still learning. :)
Oh, and separate the main plugin file from the class declarations.