The use of a modular folder structure?

Question

I'm working with a MVC modular structure, kind of like you can have with Zend (i'm not using Zend). The directory structure is as follows:

/www
  /Config
  /Modules
    /default
      /controllers
        indexController.php
        loginController.php
      /models
      /views
    blog
      /controllers
        indexController.php
      /models
      /views
...

I have a few question about this structure. I have a loginController in my "default" folder. Obviously a user goes to that page to login.

A logged in user can then post someting on the blog. But this is where my problem is. How can different modules share data, like user data?

In this scenario the "default" module will also have a "userModel". But the blog also displays a list of 'newest users'. So somehow it needs access to the userModel which is inside the "default" module.

And i could think of more examples where a certain module needs data from another module.

But this means that a 'module' is in a way almost always dependant on another module. So that's why i don't see any use in this structure. Or am i doing something wrong here..??

Is there any thought behind not beeing able to access some other module's models? In genereal you will only have one user table and one session for your visitor and those objects should be accessable in any module. — Basti, Apr 01 '12 at 13:03
@Basti Well, i thought a 'module' should be a standalone thing. So suppose you were working on the same framework is i am, then it would be no problem if you use a 'module' from my application. But if one module depends on another (like querying a certain model for data), then what's the use of this structure..?? I might aswell just use a "Controllers", "Models" and "Views" folder structure instead of separating it all like i described above. — w00, Apr 01 '12 at 13:12
@w00 Sounds like what you're trying to do is similar to Django's "apps" - you might want to look into them. The point of those is encapsulation, not total isolation. That is, it's okay for a module to depend on other modules, as well as expose some functionality, as long as this isn't done by poking around internals of a module. The way I'd do this is by letting a module work with models of another module, but preferrably using specific controller methods of that module intended for this purpose. — millimoose, Apr 01 '12 at 13:37

score 1 · Accepted Answer · edited May 23 '17 at 10:34

I would actually rethink what exactly you put in the modules.

The structures from Model layer should be shared between different modules (also .. your naming convention sucks: modules, models, models, modules, module models .. confusing). The modules are there to package the the part related to interaction.

When you work with domain business object representing "article", logic does not magically change from module to module. Instead there are just limits to what each user can do with it. Depending on, if user is authorized to performs some command or not.

You might benefit from reading this SO topic .. while more focused on authorization at controller's level, the same ideas can be applied on domain objects.

Also, you should carefully read M. Fowler's article on GUI Architectures.

score 0 · Answer 2 · answered Apr 01 '12 at 13:30

It seems that the 'module' approach is the one that doesn't fit here. In MVC you have only three entities: Model View and Controller.

Controllers can load any model, for example as you mentioned: post_controller needs both post and user models so let it be that way. Because models represents data, it is incorrect to have two user models doing the same thing.

So I would get rid of the module approach because it is an anti pattern you notice that when start repeating classes and/or code through all the application.

The use of a modular folder structure?

2 Answers2