SitePoint Sponsor |
|
User Tag List
Results 1 to 25 of 61
Thread: Modular Architecture
-
Sep 8, 2007, 16:46 #1
- Join Date
- Sep 2006
- Posts
- 232
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Modular Architecture
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.
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:
Code:modules/ home/ controllers/ models/ views/ contact-us/ controllers/ models/ views/
I'd like to know your opinion on this
Thanks!
-
Sep 8, 2007, 18:30 #2
- Join Date
- Feb 2006
- Posts
- 281
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I would use:
modules/
controllers/
contact-us/
models/
contact-us/
views/
contact-us/
Parts are reusable between pages then.
-
Sep 8, 2007, 22:15 #3
- Join Date
- Mar 2007
- Location
- Czech Republic
- Posts
- 375
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I would use:
Code:core/ controller/ model/ views/ modules/ contact-us/ events/ ...
-
Sep 9, 2007, 02:57 #4
- Join Date
- Aug 2007
- Posts
- 92
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
PHP Code:model/
modules/
home/
contact/
-
Sep 9, 2007, 03:18 #5
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Sep 9, 2007, 04:28 #6
- Join Date
- Sep 2006
- Posts
- 232
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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?
Code:modules/ home/ controllers/ models/ views/ contact-us/ controllers/ ContactUs.php ContactUsBackend.php ContactUsAjax.php models/ views/
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:
Code:modules/ contact-us/ controllers/ ContactUs.php ContactUsBackend.php ContactUsAjax.php models/ views/ install/ ContactUsInstall.php
Something is modular if it includes or uses modules which can be interchanged as units without disassembly of the module
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?
-
Sep 9, 2007, 04:38 #7
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
> 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.
-
Sep 9, 2007, 05:04 #8
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...
-
Sep 9, 2007, 08:06 #9
- Join Date
- Sep 2006
- Posts
- 232
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
Code:project * app o controllers + NewsController.php o models + NewsModel.php o views
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.
-
Sep 9, 2007, 08:08 #10
- Join Date
- Sep 2006
- Posts
- 232
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Sep 9, 2007, 09:17 #11
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
-
Sep 9, 2007, 09:53 #12
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
> 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.
-
Sep 9, 2007, 15:10 #13
- Join Date
- Jul 2004
- Location
- Netherlands
- Posts
- 672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Go visit my site :-D you know you want to ;-)
www.mech7.net
-
Sep 9, 2007, 16:43 #14
- Join Date
- Sep 2006
- Posts
- 232
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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?Last edited by phpimpact; Sep 10, 2007 at 15:34.
-
Sep 10, 2007, 15:21 #15
- Join Date
- Sep 2006
- Posts
- 232
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Sep 11, 2007, 01:30 #16
- Join Date
- Oct 2002
- Location
- Edinburgh, UK
- Posts
- 1,743
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
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.
-
Sep 11, 2007, 02:38 #17
- Join Date
- Oct 2004
- Location
- Birtley, UK
- Posts
- 2,439
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
Sep 11, 2007, 03:04 #18
- Join Date
- Sep 2006
- Posts
- 368
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
@gRoberts
i found http://www.phpwact.org/ site has alot of interesting info on php
-
Sep 11, 2007, 05:40 #19
- Join Date
- Aug 2007
- Location
- Kiev, Ukraine
- Posts
- 28
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Sep 11, 2007, 07:54 #20
- Join Date
- Sep 2006
- Posts
- 232
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Sep 12, 2007, 10:14 #21
- Join Date
- May 2004
- Location
- Central USA
- Posts
- 806
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.Stackbox CMS - Full edit-on-page drag-and-drop CMS
Autoridge - Vehicle information & maintenance part numbers
Twitter | Blog | Online Javascript Compressor
-
Sep 12, 2007, 13:09 #22
- Join Date
- Sep 2006
- Posts
- 232
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Definitely! I find this architecture very convenient when it comes to web development.
I do something similar:
Code:modules/ contact-us/ controllers/ ContactUs.php ContactUsBackend.php ContactUsAjax.php models/ ContactUsModel.php views/ index.html install/ ContactUsInstall.php
Code: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
-
Sep 13, 2007, 07:31 #23
- Join Date
- May 2007
- Posts
- 28
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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?
-
Sep 13, 2007, 12:38 #24
- Join Date
- May 2004
- Location
- Central USA
- Posts
- 806
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.Stackbox CMS - Full edit-on-page drag-and-drop CMS
Autoridge - Vehicle information & maintenance part numbers
Twitter | Blog | Online Javascript Compressor
-
Sep 13, 2007, 14:40 #25
- Join Date
- Sep 2006
- Posts
- 232
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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?
Bookmarks