• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Which HMVC library do you prefer? Why?

[quote author="WanWizard" date="1291044823"]@wiredesignz,

You sound like a broken record. There is no "true HMVC" (a search reveals that you are the only one using this term), and there is no death penalty on "not following" whatever pattern you think people should follow.[/quote]

You wrote this did you not?

[quote author="WanWizard via Bitbucket" date="1291044823"]

Modular extensions for CodeIgniter have been around in some shape or form for quite some time: Modular Extensions, HMVC, Matchbox and Modular Separation.

While designing an application framework based on CodeIgniter, I needed a much more flexible system than what is on offer by the extensions mentioned above.

A module in my definition is a complete CodeIgniter mini-application.

It needs to support all elements you have in a regular application folder: controllers, models, views, libraries, helpers and config files. All these elements must be loadable using the CodeIgniter standard practices, automatic, and with a minimum of configuration. And this includes controllers loading other controllers, and models loading other models, to support true HMVC.

At the same time, the solution needs to support modulair routing. Not with a fixed format (for example the first URI segment has to be the module name), but using regular CI routing rules.

Also, I wanted as little impact on a standard CodeIgniter installation as possible, as every extension of a core library method might break some CodeIgniter functionality in the future. Some extensions however, are unavoidable. These are documented in detail below.


* Supports routing to module controllers
* Location of your modules is configurable at runtime
* Supports cross module calls, also to controller methods
* Uses standard CodeIgniter routing, no Router library modifications
* Introduces $this->load->module() via a Loader library extension
* Support for the default index() method and the _remap() method when routing
* Supports loading models without CI object assignment, to support ORM libraries
* Supports module controller return values for true HMVC...[/quote]

You, like a few other people I won't mention, like to use catch phrases and hype to try and impress people here who might know less than yourself. But rest assured you do not impress those who know better.

Ok, I'll stick my dick in the grinder.

Why is it not right to load a model within a model?

I have a data model that does some helpful db stuff. I load that in quite a few other models. I guess you could call it a model helper.

If I don't do that, I violate the DRY principle, which in my opinion, is a pretty good principle.

If you use a model as helper and it is never used by itself then it isn't a model is it? It is a helper.

A model encapsulates access to the database or any other external data source (the real world). It is not specific to a single table in a database.

If you want to use models as data objects then use a data mapper or ORM.

So, I violate DRY?

My "helper" model does some very abstract things. Many models can benefit from this.

You see, a model can be seen as an abstraction from the controller itself. Why stop there?

If a further level of abstraction can be wrought that enhances other models, why not use it?

Actually, if you view models as classes, it's like suggesting that (somewhat) one class should not extend another.

A model is not an abstraction from a controller. They are designed for different purposes.

You can use any class to do any job, but you may violate the MVC design pattern if you do.

You can also do whatever you want to. It's your code. But don't try to justify poor design by saying "why not".

There is nothing stopping you from extending models from each other if you need to re-use some functionality. Simply add it to a model base class, and go from there.

So, if I have a model that needs a common function, I need to code that in every such model?

This is not a dry (forgive the pun) philosophical debate. The implication is that each model must do everything that it needs to without external support?

If not, how?

Edit: a base model class is nothing different than invoking another model from within that model.

Read my edit above.

DRY is the correct way to code. But there is always more than one solution too.

You will need to figure this stuff out for yourself.

[quote author="nuwanda" date="1291128285"]a base model class is nothing different than invoking another model from within that model.[/quote]

That comment is totally wrong. You are not loading another entity, the parent class is part of the final object.

But it's not from any practical viewpoint.

I could write an app that does nothing but extend classes ad infinitum.

For the purposes of MVC, invoking one model from another is perfectly legitimate.

Everything else is semantics.

You can justify poor application design in any way you feel is appropriate. It is your application. Legitimacy is only your opinion too.


Demonstrate how calling one model from another is not efficacious.

Hell, using active record in CI is simply invoking one level of abstraction in another.

Why is that sacrosanct, and not invoking further abstraction via another model? The invoked model is after all, just another CI model class.

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2021 MyBB Group.