Do modular PHP frameworks really improve applications?

Question

One of the goals of modular frameworks like Kohana or Alloy is to make it easy to add and remove components (i.e. "plugins" or "modules").

However, in all the larger projects I have ever worked - the system often becomes dependent on the modules it is built on. After all, that is why they are there - to build with them.

So, I'm wondering if the concept of building distinct separate sections of a web application as independent modules is even a good idea to begin with? For example, we may build a general user, forum, and blog module - but each project is different and usually involves building many layers of abstractions to add new features - or editing the files directly to customize them. I can't re-use the same module on multiple projects.

In other words, they are no longer just a plug-in-play add-on to the site.

Now I'm not confusing this with proper class design to ensure un-coupled MVC and library logic. But I'm wondering if "MMVC" was a superfluous effort to apply proper class design concepts to application design as well. After all, many migration systems or database libraries like Doctrine require all the relations spelled out in the models from day one, thereby linking the entities.

Is it one of those things that sounds like a good idea when the project starts, but eventually is shown to be a useless feature? Do modules have their place in systems like wordpress - but not in frameworks where you are obviously building something custom?

Answer 1

The purpose of modules and frameworks is not so much to achieve independence of functions as it is to achieve reusability and flexibility. In most other occupations, this kind of reuse of function and flexibility is central to achieving success.

Think about how difficult it would be to work on your car if you had to buy a whole new tool set for each car, because the tools were not interchangeable. Or worse, you hae to build the tools from scratch, because there wasn't a factory to create them. Both of these concepts (universal pluggability and object factories) are present in well-written modules and frameworks.

...but each project is different and usually involves building many layers of abstractions to add new features - or editing the files directly to customize them. I can't re-use the same module on multiple projects.

You are describing tight coupling, an undesirable trait of software that's intended to be reused. Properly written libraries, frameworks and modules achieve loose coupling through software patterns such as Inversion of Control, message passing, and universally-understood communication methods such as REST and XML. These are not the only methods by which loose coupling can be achieved.

Obviously, it is impossible to write a completely decoupled system; one part of the system has to know something about the other part of the system, or nothing gets accomplished. But a high degree of decoupling can be achieved nevertheless.

Writing modular software takes more work and forethought than writing tightly-coupled systems, but the effort can be worth it, especially when writing a framework or library that will be used by many people.

Answer 2

The ubiquitous MVC pattern of today's frameworks is a form of forced modularity...but it's not the kind of feature-based modularity that most people think of when they think of the word. Old-school applications were traditionally a lot more feature-modular, which made them more transparent and better reflections of the user experience.

Feature-based modularity defines groups of source files and/or code structures based on application features, for example:

• a login process
• a new account registration process
• a discussion board
• a searchable product catalog
• a new order entry process
• etc.

So for a login process, you might have:

• source files named things like "login.php" and/or "class.login.php" and/or "login_view.php", etc.
• code functions named things like "RenderLoginForm()" and/or "ProcessLoginForm()", etc.
• code classes named things like "LoginProcess", etc.

To be truly modular, each module needs to interoperate with central application controllers, automated test scripts, etc. To do this, you might have:

• The entire module wrapped in a class/function that can be created/called by a central routing-type program
• The entire module contained in a source file that can be called or included by a central routing-type program
• Input and output parameters that can be passed and returned by the functions to indicate which records are affected, what the module does, what happens before and after, etc.

MVC modularity neatly separates languages: SQL (in the model), HTML/CSS/JS (in the view), and PHP/Python/Ruby (in the controller). But MVC knows nothing about the features. A truly feature-modular application will have a unique architecture that can only be designed by someone who understands the user experience and business needs. MVC, like object-oriented programming, is merely a design pattern. It's a poor substitute for a true, unique, relevant, modular application architecture.

MVC rules the landscape today and, at times, it is a wonderful pattern. But someday people will wake up and throw off its overused, arbitrary, clumsy shackles and rediscover unique, custom application architectures.