Edward Haber wrote:
>
> First of all, had I known you were a Zend engineer...
>
Former Zend engineer. I worked on the project 9/2006-10/2007, mostly on
Zend_Db and PM stuff. I'm no longer contributing the project, but I like
answering questions on mailing lists.
Edward Haber wrote:
>
> 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.
>
Yes, I agree. If the split seems to create an anti-DRY solution, it's a
clue that you're actually splitting functionality that belongs in one
module.
In a modular application, there should be no need to duplicate code in an
anti-DRY manner, because each module has completely separate functionality.
I mean, you might have two classes that are both called "Pages" by
coincidence, but they do completely different things, probably even
accessing different database tables. This is not a violation of DRY, but
also it's pretty unlikely that both classes would be needed during a given
request.
Edward Haber wrote:
>
> 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.
>
I didn't say you had to have a single model directory. I would create a
model _hierarchy_. You can organize your model classes in multiple
subdirectories under that hierarchy, and then reference the top of the
hierarchy in your include_path. Of course your class names should conform
to PEAR naming.
app/models/Admin/User.php:
class Admin_User extends Zend_Controller_Action_Abstract { ... }
app/models/FrontEnd/User.php:
class FrontEnd_User extends Zend_Controller_Action_Abstract { ... }
Actually it's likely that one class is an extension of the other, to add
functionality. That way if you fix a bug in the base, it applies to the
other.
app/models/Admin/User.php:
class Admin_User extends FrontEnd_User { ... }
Edward Haber wrote:
>
> 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?
>
Because it's simpler to group code using directories, for example. You
don't need the complexity of modules in most circumstances. Only when you
have the possibility of class name conflicts because you're dropping in
multiple modules potentially from different sources. In those cases, it's
very unlikely that you would need to support inter-module class references.
Edward Haber wrote:
>
> Thanks for your notes. I hope to learn a lot from the members of the list.
>
Thanks to you too. These are just my views, the way I would approach a
problem. By the way, though I tend to write in an unequivocal style, I do
realize there's more than one way to do it, and I support you organizing
your project the way it makes sense to you. It's just not the way I'd do
it. :-)
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-tp19607614p19632344.html
Sent from the Zend Framework mailing list archive at Nabble.com.
