Когда использовать модули в Zend Framework? - PullRequest
13 голосов
/ 26 августа 2010

При настройке новых проектов ZF у меня обычно есть такая структура каталогов:

  • приложение
    • модули
      • по умолчанию
        • контроллер
        • формы
        • вид
        • модели
      • admin
        • контроллер
        • формы
        • просмотр
        • модели
    • язык
    • общий
      • модели
  • библиотека
  • public

Я использую только модули, когда, например, разметка разная, или база данных разная, или, конечно, когда ееочень особый случай, такой как админ-бэкенд или форум / доска объявлений.Тогда у меня есть контроллер для различных частей приложения.например, JobController, ProductController и т. д.

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

Его настройка работает и не ошибается, но я никогда не видел такой подход, он кажется ненужным сложным.

Итак, чтобы закончить:

  1. Когда вы будете использовать Модули, а когда будете использовать Контроллеры?
  2. По какому правилу вы выбираете модуль или не модуль?
  3. Каковы минусы и плюсы настройки моего коллеги с вашей точки зрения?
  4. Каковыминусы И плюсы моей установки на ваш взгляд?

TIA

Rufinus

EDIT : см.http://mwop.net/blog/2012-04-30-why-modules.html для получения информации о переработанных модулях в ZF2.0

Ответы [ 4 ]

9 голосов
/ 26 августа 2010

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

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

6 голосов
/ 26 августа 2010

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

Так же, как вы. Для основных разделов моего сайта, таких как интерфейс, раздел администратора, раздел участников и т. Д. *

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

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

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

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

Каковы минусы и плюсы моей установки по твоему мнению?

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

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

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

myapp.com / контакт

myapp.com / о

myapp.com / Участники / Профиль

myapp.com / Участники / профиль / редактировать

myapp.com / Участники / почта

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

5 голосов
/ 30 августа 2010

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

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

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

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

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

2 голосов
/ 26 августа 2010

В) Когда вы будете использовать Модули и когда будете использовать Контроллеры?

А) Для меня все зависит от размера приложения.Если у вас более 10 контроллеров, вы можете подумать о реорганизации некоторых из них в отдельный модуль.Если вы планируете создать ДЕЙСТВИТЕЛЬНО БОЛЬШОЕ приложение, возможно, стоит его разбить на модули перед запуском.

В) Какое правило вы выбираете для модуля, а не для модуля?Я сказал, что у меня более 10 контроллеров.

В) Каковы, на ваш взгляд, минусы и плюсы установки моего коллеги?

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...