First of all, had I known you were a Zend engineer I probably wouldn't have opened my big mouth. I'm new to the list. :-) But since it's already open, i'll just offer a few points of view from my perspective.

On Sep 22, 2008, at 12:55 PM, Bill Karwin wrote:
Edward Haber wrote:

Another problem with the proposed solution is that it only makes one
module's models path active at a time. I think the ideal when working
with multiple modules is to have the option of using model code from
more than one module models directory at a time, especially in cases
of interdependency.

No, that's not ideal, that's actually what I was recommending to _prevent_.

I see your point that having all the models directories of all modules in the include path leads to namespace collision in a modular framework like Joomla. I was under the impression you were making a modular application where the code is grouped by functionality rather than a third-party-capable modular framework.

A module has its own controllers and views, and should have its own set of
models as well.  One module should not be allowed to reference another
module's controllers, views, or models. If you follow this rule, then it
solves all the problems of ambiguity and collision.

In my opinion, if you have three modules implementing a Pages model that has a duplicate "fetchMyPages()" method (say with differing parameters per module) then it seems anti-DRY to repeat the same file/ class/method three times (then keep them sync'd when making bug fixes, then write three sets of test classes, etc.). It comes down to (for me) if the class in question is used in the exact same context in multiple modules. If it's three unrelated types of pages that has one solution. If it's three versions of basically the same class and methods then it seems anti-DRY to me.

Don't separate your application into modules if the modules aren't separate. If you want to share model classes among all your controllers, then don't
create modules.

In my case, It was a lot easier to manage the front-end (controllers and views) within modules but just use a single model directory. This particular organizational method helped the front-end developers find code more easily and allowed for teams to work more independently. These solutions are unique to the needs of each application. If it best suited your application, there's no reason you couldn't have fifty front-ends (of controllers/views) connected to one set of models.

It also suited the application well, which has three front-end areas (which I made modules) where users of one area never are users in another area. I agree I would approach a Drupal/Joomla-like architecture differently, but this architecture is clear, obvious, and breaks no MVC conventions.

If however it is a must that you remain encapsulation and that these
modules are dropped into other apps and need to work this way, then I
would change the names of your models entirely.

This doesn't work in general, if you drop third-party modules into your app, or drop your module into someone else's app. Only if you have control over the class naming of all modules in an app does your recommendation work. If you're the author of all the modules in the app, then why are you using
modules at all?

The purpose of modules is to provide isolation between sets of classes.
Many people seem to use modules to create friendly URL's like
"/myapp/admin/controller/action" but you can do this by creating custom
router rules.  You don't have to use modules simply to define URL's.

This seems unnecessarily strict. In my opinion, modules can be *more* than this or *less* than this depending on the requirements of the application. Part of the beauty of the Zend Framework (and PHP) is that it is so flexible to different architecture requirements. I agree it's really not that hard to write a route. I'm using plenty of them in the app. But why not, if it suits the grouping of your code, and makes the urls work, take advantage of built-in features of the framework?

Thanks for your notes. I hope to learn a lot from the members of the list.

Eddie

Regards,
Bill Karwin
--
View this message in context: 
http://www.nabble.com/multiple-models-with-same-name-%28m1-models-pages.php-and-m2-models-pages.php%29-tp19607614p19612115.html
Sent from the Zend Framework mailing list archive at Nabble.com.


Reply via email to