Когда использовать модули в Zend Framework?

Ответ 1

Что такое минусы и плюсы моей настройки коллеги в вашей точке зрения?

Улучшение повторного использования. Предполагая, что ваш коллега оставил код внутри модулей независимым от других модулей, он фактически создал автономный проблемный домен. В отличие от вашего подхода, он может более легко скопировать весь модуль на другие приложения.

Ответ 2

Когда вы будете использовать модули и когда вы будете придерживаться контроллеров?

То же, что и вы. Для основных разделов моего веб-сайта, таких как front-end, раздел admin, раздел участников и т.д.

Каково ваше правило для выбора модуля или не модуль?

Является ли это частью основного сайта или своего небольшого мира, только связанного с интерфейсом? Особенно в отношении дизайна. Как вы управляете несколькими модулями, использующими один и тот же макет?

Каковы минусы и плюсы моего коллега в вашей точке смотреть?

Боже мой. Все эти папки вообще ничего. Почему у вас есть страница о странице и контакте в двух разных файловых структурах? И где он ставит администратора и членов, если он использует модули для простых страниц?

Каковы минусы и плюсы моей настройки с вашей точки зрения?

Действительно, противоположное вышеизложенному. Простая для понимания и когерентная структура.

Его стоит добавить его способ, которым команда zend намеревалась использовать его ссылка

Еще одна вещь, о которой стоит подумать, - это то, как выглядят ваши URL.

myapp.com/contact

myapp.com/about

myapp.com/members/profile

myapp.com/members/profile/edit

myapp.com/members/mail

Это простой способ помочь организовать то, что будет в модулях или контроллерах.

Ответ 3

... как Job-Module, Product-Module, каждый из этих модулей имеет в основном 2 контроллера IndexController и AdminController.

Это описание создает для меня красный флаг. ЕСЛИ это был действительно большой проект, который должен был полагаться на высокую возможность повторного использования, и ЕСЛИ он закодировал такие модули таким образом, чтобы они могли работать независимо от других модулей в системе и ЕСЛИ необходимо изолировать область администрирования для каждого модуля, то это можно считать разумным подходом.

Но я бы предположил, что существует зависимость между Job и Product, и в этом случае этот модульный подход звучит как чрезмерная инженерия. Особенно, если, как представляется, применяется произвольное "правило" (например, один бизнес-объект для каждого модуля).

Кроме того, большинство инфраструктур MVC предполагают, что если у вас есть модели Job и Product, у вас есть контроллеры Job и Product (а не IndexController для каждого объекта). Целью модулей является разделение логических и презентационных областей вашего сайта, а не разделение бизнес-логики.

Хотя он, вероятно, ни здесь, ни там, насколько подходит MVC, мне не имеет смысла создавать модуль, который не может полностью функционировать от других модулей.

Ответ 4

Q) Когда вы будете использовать модули и когда будете придерживаться контроллеров?

A) Для меня все зависит от размера приложения. Если у вас более 10 контроллеров, вы можете подумать о реорганизации некоторых из них в отдельный модуль. Если вы планируете создавать приложение REALY BIG, возможно, стоит потратить его на модули перед началом работы.

Q) Каково ваше правило для выбора модуля или модуля?

A) Как я уже сказал, имеет более 10 контроллеров.

Q) Каковы минусы и плюсы настройки моего коллеги в вашей точке зрения?

A) Если это небольшой проект, он над инженерией, что усложнит работу других разработчиков и займет у него больше времени, чем необходимо для разработки в первую очередь. Он также рискует запутать себя.

Q) Каковы минусы и плюсы моей настройки в вашей точке зрения?

A) Мой ответ выше почти полностью охватывает его, если это небольшой проект, ваш путь будет более быстрым и менее запутанным в долгосрочной перспективе. Я предпочитаю этот подход и просто рефактор, если область увеличена.