Modular Architecture

[phpimpact]

One of the advantages of a modular architecture, where the modules are self contained, is that you can replace or add any module without affecting the rest of the system.

Wikipedia:

A module is a self-contained component of a system, which has a well-defined interface to the other components; something is modular if it includes or uses modules which can be interchanged as units without disassembly of the module. Once the module exists, it can easily be connected to or disconnected from the system.

When it comes to Web development and high level frameworks, Symfony is the only one that gives you the option to implement modules, but because the system wasn't created with a Modular Architecture in mind, it fails to provide all the advantages this architecture has to offer.

So, What if a high-level framework has components and modules. And those modules are self contained and they have their own MVC implementation. Their own Action Controllers, Models and Views. What if a website is built based on modules? For example:

modules/
    home/
        controllers/
        models/
        views/
    contact-us/
        controllers/
        models/
        views/

It might take us 1 day to create the "contact-us" module, but once we have it, it will only take us 1 hour to implement it in another site. So, is the modular architecture a good approach to RAD?

I'd like to know your opinion on this

Thanks!

[blueyon]

I would use:

modules/
controllers/
contact-us/
models/
contact-us/
views/
contact-us/

Parts are reusable between pages then.

[Mastodont]

I would use:

core/
  controller/
  model/
  views/
modules/
  contact-us/
  events/
  ...

[pakmannen]

Modules probably share much of the domain logic, so I'd only have one model folder. Of course that means you can't just plop them into another project without also adding the appropriate models.

model/
modules/
  home/
  contact/ 

[Dr Livingston]

Umm...

What I've found is that there is no point [MVC] in having a View pertaining to a given module, as the template tends to be too fragmented in regards for one View to meet specific requirements, so out goes that.

At the end of the day, you are really only left with your Model, which is your module; When it comes to crunch time, it's the Model that does what it does that makes a module a module; A Controller isn't here nor there, since there are a variable number of differences in where a request comes from.

I leave it to the application it's self to implement the Controller, so the only real benefit is that you get maximum reuse on your Model(s) only but that's what you want anyway. Otherwise, if you retain your Controller (and/or View) along side a module, you'll have a noticeable amount of drag later.

[phpimpact]

Ok, but I'm still going to push this a little bit further.

Following the DRY principle, what if I add a Module component that creates a bridge between 2 or more modules? This will make all the modules accessible from anywhere within a project. That means that all the Models, Views and Controllers will be shared.

Also, we all know what an Action Controller does right, what if we add more than one action controller per module? A front-end Action Controller, a back-end Action Controller and an ajax Action Controller?

modules/
    home/
        controllers/
        models/
        views/
    contact-us/
        controllers/
            ContactUs.php
            ContactUsBackend.php
            ContactUsAjax.php
        models/
        views/

So we access the front-end controller like this:
http://www.domain.com/contact-us

The back-end controller like this:
http://www.domain.com/admin/contact-us

And the ajax controller like this:
http://www.domain.com/ajax/contact-us

What if we add an installer as well, why not? With the database schema and some info about the module:

modules/
    contact-us/
        controllers/
            ContactUs.php
            ContactUsBackend.php
            ContactUsAjax.php
        models/
        views/
        install/
            ContactUsInstall.php

Following the Modular Architecture, this will allow us to interchange modules.

Something is modular if it includes or uses modules which can be interchanged as units without disassembly of the module

Now, from the project management point of view, wouldn't this also help to determine the development time of the project and assign resources. For example, if the information architect gives me a list of 20 pages, sections or modules that we need to build, I can separate them into groups: Simple, Standard and Complex. I will assign the simple and standard modules to the junior developers, and the complex ones to the senior developers.

For me a modular approach makes sense when it come to web development, but, why no one is using it? That's my question, what are the pros and cons of building a system like this?

[Dr Livingston]

> That's my question, what are the pros and cons of building a system like this?

Complexity. If you want a modular system, then it's not just about the modules themselves, but the need to manage them effectively within a given environment, such as your application for example.

[feketegy]

I think that in order a website to be compact, fast and easily manageable we should consider the KISS Principle and for mid to big projects we could use MVC pattern. For small projects, like static websites or little database interaction is too complex to implement a MVC pattern...

[phpimpact]

Yes, the KISS principle, one of my favourites. This is one of the reasons why I'm trying to use not only a good design pattern, such as MVC, but also a solid system architecture before developing a web site.

At the moment we are basing the architecture of our system on the file structure. It has its advantages, yes, but it also has a lot of disadvantages.

project
    * app
          o controllers
                + NewsController.php
          o models
                + NewsModel.php
          o views

Why is everything everywhere? Because we got used to see it that way?

What if the NewsController also has public resources, such as javascript or css files? What if we copy the NewsController.php to another project. We break the system?

Configuration: What if each Action Controller has a different configuration files? Where are they stored?

Inheritance: What if an Action Controller needs to have child Controllers? What if an Action Controller needs to inherit the configuration from another Action Controller? How do you do this based on this architecture?

How can a Sys Admin limit access to the most important controllers, if they are all together?

I'm not saying that we got everything wrong copying everything from other systems. I'm just saying that it's time to stop thinking about the design pattern, and focus a little bit more on the system architecture.

[phpimpact]

> That's my question, what are the pros and cons of building a system like this?

Complexity. If you want a modular system, then it's not just about the modules themselves, but the need to manage them effectively within a given environment, such as your application for example.

But, from the user or developer perspective? If it's the developer, I completely agree.

[feketegy]

You could use a framework. For ex. CodeIgniter for PHP implements very well the MVC pattern, very easy to learn too. You should check it out. Amongst the top framework I consider the following: CodeIgniter, CakePHP, Symphony

[Dr Livingston]

> If it's the developer, I completely agree.

Yes, that is what I was meaning

> You could use a framework.

You could; A framework though only has the implementation, so you don't have to do your own implementation. What I was referring to with the manageability of using modules, putting them together, and their maintenance from the application point of view?

For most people, a module is a component that may well be a part of the overall request, ie Something that sits on the side of the page once completely generated. But... That may not always be the case, as a request may only require a operation to be performed, and nothing more in some cases.

Nothing is returned or outputted therefore; This is why I (after hindsight) taken the point of view that a module is more or less, the Model only. That's how I look at it, so the milage may vary for other members.

[pixelsoul]

So, What if a high-level framework has components and modules. And those modules are self contained and they have their own MVC implementation. Their own Action Controllers, Models and Views. What if a website is built based on modules? For example:

modules/
    home/
        controllers/
        models/
        views/
    contact-us/
        controllers/
        models/
        views/

This is pretty much like Joomla 1.5 + Framework is doing Except that modules are called components, and blocks are called modules

[phpimpact]

You know what, you are right. I've seen this architecture in some CMS and Joomla is a good example.

So, if content is dynamic in this days, and a CMS like Joomla has adopted this architecture based on their experience, we can agree that MA is a good aproach when it comes to web development right?

How come every day there's a new framework? Maybe this reflects the problem PHP is going trough. People are creating frameworks because they can't find a a solution to their problem.

Symfony? It's expensive to maintain, we need to hire senior developers. CodeIgniter or Cake? PHP 4, no thank you. Zend? Umm, a low-level framework, but we also need to manage the content. Joomla, is too much, we only need to build a small website.


[edited] removed: why are we so structured?

[phpimpact]

When it comes to frameworks, I think there are 3 different type of users:

1. Web Developer

She wants a system that:

- Is easy to use.
- Works on any server.
- Has non-technical documentation.

2. Programmer

She wants a system that:

- Is object-oriented.
- Is easy to extend.
- Has technical documentation.

3. System Architect

She wants a system that:

- Implements the right design patterns and programming paradigms.
- Is flexible and easy to extend.
- Has technical documentation.

Based on this I can tell you who is going to use what:

1. Cake or CodeIgniter.
2. Symfony and maybe Zend.
3. Zend.

[Mike Borozdin]

Modules probably share much of the domain logic, so I'd only have one model folder.

Not exactly, without being too abstact I'm going to say that we mainly use a database as a data storage, so the core has its own set of tables and each modules has its own set of tables, so it's ok that the module has its own model classes.

Nothing is returned or outputted therefore; This is why I (after hindsight) taken the point of view that a module is more or less, the Model only. That's how I look at it, so the milage may vary for other members.

You're being too abstract, I think. Let's take phpimpact's example of the contact form. It's a form and sure it has to be processed, what is responsible to form processing? Controller.

[gRoberts]

Sorry to hijack your thread....

I've been teaching my self PHP for a while now, and I am wanting to start on building an CMS, but i'd like to go the MVC Route.

No matter how hard I try, i've not found a solid tutorial that takes you through the basic steps, outlining the layout, and logic.

Anyone got any idea's?

thanks

[mihd]

@gRoberts

i found http://www.phpwact.org/ site has alot of interesting info on php

[golotyuk]

I like using plugins, and not modules. Run them on a hook-based events. I think that's quite good for componenting in your application and thus having reusable code.

[phpimpact]

Ok, but plugins and modules are different things.

For example Word Press or Facebook, they have a web application that provides an API that allows third parties to create plugins to interact with that application.

The architecture of the application itself is what I'm more interested in. And how a modular approach fits well in web development, or not.

[Czaries]

Good thread!

I am actually pretty far along in working on just such a framework myself. I call the individual "modules" components, and place them in a directories like you have. The only difference is that more often than not, I only need one controller and model for any given component, so there are no separate /controllers/ and /models/ directory - they are instead aptly named, like 'HomeController.php' and 'HomeModel.php' so they are easy to distinguish.

I do web development for websites on the side, and I came to the realization that most people often want the same general components and functionality, just perhaps implemented in a slightly different way. By making the framework in a modular format (as you have described), it allows me to simply drag and drop a single folder into a framework instance instead of going in and grabbing all the different models, controllers, views, etc. and iterating over several folders and copy/paste actions to get what I want. It may not be ideal for large complex and integrated systems, but it works wonderfully on small to medium websites who need the functionality.

[phpimpact]

Definitely! I find this architecture very convenient when it comes to web development.

I do something similar:

modules/
    contact-us/
        controllers/
            ContactUs.php
            ContactUsBackend.php
            ContactUsAjax.php
        models/
            ContactUsModel.php
        views/
            index.html
        install/
            ContactUsInstall.php

Then, you can take this a step further and create a CMS where you display a Site Structure that allows you to assign modules to pages. For example:

Page               Module          URL               Action
-----------------------------------------------------------------
- Home             home            home              edit | delete
- News             news            latest-news       edit | delete          
- Products         products        products          edit | delete
  + Sales          products        on-sales          edit | delete
  + Shops          map             where-to-find-us  edit | delete
- Contact Us       contact-us      contact           edit | delete

Thanks for sharing your working methodology with us

[mr.vain]

Nice thread!

Modular architecture seems to be a good approach. I think of it as a divide et impera strategy to solve complexity problems, when applications get bigger. So "modular" means for me, that functionalities were splitted from a monolithic architecture into smaller components. These components implement a certain "module" interface. I use the FrontController-Command-Interface for them.

Although the idea exists, that one can interchange modules between different CMS or Frameworks, i have never seen this actually happen.
When it comes to this, you will find lots of "bridging-code".

But what's the difference between modules and plugins?

Fmpov, a plugin adds a small bit of functionality to a module at a certain lifecycle position of the application, is that right?
So i would ask, what are the standard positions for such plugin-hooking?
Maybe pre- and post module execution and pre- and post rendering?
With which pattern (Eventdispatcher?) could i implement a plugin architecture?

[Czaries]

Then, you can take this a step further and create a CMS where you display a Site Structure that allows you to assign modules to pages. For example:

Page               Module          URL               Action
-----------------------------------------------------------------
- Home             home            home              edit | delete
- News             news            latest-news       edit | delete          
- Products         products        products          edit | delete
  + Sales          products        on-sales          edit | delete
  + Shops          map             where-to-find-us  edit | delete
- Contact Us       contact-us      contact           edit | delete

Thanks for sharing your working methodology with us

You're welcome! That's what forums like this are for!

I actually take a slightly different approach than you have above with a pages container for your modules, in that I let the components (your "modules") themselves control the display. All my components extend from a Base_Controller that has a render() function. When the component is done doing it's stuff, it can call the render() function to wrap itself in the common layout (or pick different one). So instead of creating pages that run and then call the assigned component, the component is run and then calls the render() function to create the page around it. I prefer this method because it allows the components to build the page how they want with no other master configuration table needed. It eliminates a dependency and another step to go through during setup. This helps meet my original design goal with fully self-contained components and only a simple drag & drop operation being necessary for installation.

[phpimpact]

Umm, very interesting Czaries

There's a slightly chance that we are doing it similar. My Controller_Router component (class) takes the URI and decomposes it into parameters and determines which module and action of that controller should receive the request. I package all this into the Controller_Request_Http, that is then processed by the Dispatcher. Is a standard way of doing it.

Now, what I added in the Controller_Router is the option to map the module to a site tree in the database, but this is optional. Is just in case you want to build a CMS, like the example I showed above.

Your module (component) extend Base_Controller, mine extends an abstract class called Module, and this one extends Module_Base. Actions can be mapped to methods or, optionally, to files inside the actions/ directory. I'm using Zend_View, so the action methods return a View object, that are then rendered by the Controller_Dispatcher_Frontend or Controller_Dispatcher_Backend, depending on the request.

I'm quite surprised that you built your framework using this approach, that's great! Are you using your own core classes or you built your framework on top of another one?