HMVC как отделить модули?

Question

Я делаю веб-сайт управления отправлением (HRM). Я использую codeignitor HMVC для его создания. Следующие функции включены в этот сайт:

1. Таблица, чтобы отобразить резюме листьев.
2. таблица для видов отпусков, как ежегодный, MC, срочно, другие ...

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

Согласно архитектуре HMVC мы пытаемся создать автономные модули для повторного использования. Если я создаю другой модуль для типов отпуска, я должен иметь возможность его повторно использовать, и сам модуль должен быть сам собой. Но я не могу использовать модуль leave_types в другом месте.

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

Нужно ли нам отделять модули, которые могут быть повторно использованы в будущем (например, модуль входа в систему, модуль image_gallery, модуль профиля) и сохранить все остальные вещи в одном модуле? (в соответствии с приведенным выше примером, я должен держать все, что связано оставить в одном модуле например: leave_type, leave_requests, leave_summary будут размещены внутри модуля отпуска)

Какие преимущества я получу, если я отдельно leave_type, leave_requests, leave_summary и т. д. ... в отдельные модули?

Смогу ли я их повторно использовать? Если да, то как?

В классах моделей HMVC и других активах можно обмениваться между модулями, поэтому как я могу назвать его автономным модулем или отдельным объектом, поскольку он зависит от другого модуля? (например: Мне нужно вызвать класс модели модуля leave_type внутри модуля leave_summary, чтобы показать имя типа отпуска в таблице.)

Я здесь немного потерялся. Пожалуйста, помогите мне понять. Большое спасибо!

Answer 1

Как я работаю над проектами MVC. И я согласен с вашим другом.
May times этот вопрос возникает, когда я использовал join, что мне нужно выбрать, в каком модуле я должен идти для записи запроса. Если вы напишете в одной модели, следующий разработчик напишет в другой модели.
Так что мне лучше хранить те же типы таблиц, которые обрабатывают отношения, а использование для такого же поведения использует такой подход, как модель отпуска, модель профиля и т. Д.