Блог

Главная - Вопросы по программированию - Структурирование приложения, чтобы оно было модульным

Структурирование приложения, чтобы оно было модульным

#php #model-view-controller #architecture #hmvc

#php #модель-представление-контроллер #архитектура #hmvc

Вопрос:

Я пытаюсь найти решение для следующего сценария:

У меня есть приложение, которое позволяет кому-то управлять своей адресной книгой / списком клиентов. (MODULE CLIENTS)

Кому-то, использующему это, может понадобиться список заданий, который ссылается на клиентов. (MODULE JOBS)

Кому-то еще может понадобиться список свойств, который ссылается на клиентов и задания. (MODULE PROPERTIES)

Есть ли способ сделать так, чтобы вы могли буквально:

удалите модули CLIENTS и JOBS при новой установке, и они смогут взаимодействовать

удалите модули CLIENTS , PROPERTIES и JOBS при новой установке они смогут обмениваться данными (клиент -> свойства -> задания для каждого свойства ИЛИ клиенты -> задания)

или даже удалите модули CLIENTS и PROPERTIES при новой установке по аналогичному сценарию, как клиенты / задания.

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

Я не пурист, поэтому я с удовольствием добавляю дополнительные контроллеры в модули по мере необходимости, но я просто хочу ускорить процесс.

Или было бы лучше создавать модули-наполнители, которые устраняют разрыв, и вместо этого использовать их для построения представлений??

Мне также интересно, как лучше всего спроектировать представления — на данный момент у меня есть представление, а затем «страницы», Которые являются отдельными компонентами этого представления (таблицы, формы и т. Д. — Каждая страница) -> Я просто вызываю страницы через Module::Run(если вы привыкли к codeigniter -> в основном то же самое, что и «включить») -> это здорово, но, возможно, это не лучшая система для вышеупомянутого сценария.

Заранее спасибо!

Ответ №1:

Подключение модуля

Если вы не используете фреймворк HMVC, который может «разумно» обрабатывать этот стиль (модуль) связывания, вам нужно будет каким-то образом «настроить» или «подключить» его. Хотя я не знаю ни одного фреймворка HMVC, который мог бы это сделать, я бы предположил, что если бы кто-то это сделал, вам нужно было бы запрограммировать свои контроллеры на некоторую форму «интерфейса» (термин используется свободно), чтобы он знал, как они все связаны.

Используя «неинтеллектуальную» структуру, нужно было бы использовать либо глобальный конфигурационный файл, либо файлы конфигурации модуля в какой-либо форме (например, yaml, xml, php и т. Д.), объясняющие связь между модулями. Опять же, я не знаю о такой структуре HMVC.

Все это говорит о том, что это был бы отличный проект, и он определенно продвинул бы мир фреймворков HMVC дальше, хотя я подозреваю, что это может привести к потере некоторой гибкости в способе программирования ваших контроллеров, в первую очередь из-за языка (параметров), которые каждый модуль должен был бы реализовать для общения или взаимодействия сдругой (контроллер).

Модули-наполнители

Мой предпочтительный подход и подход других фреймворков (MVC и HMVC) заключается в том, чтобы маршрут соответствовал основному контроллеру (вашему модулю-наполнителю). Затем этот первичный контроллер вызывает свои субконтроллеры (модули) и, при необходимости, субподконтролеры (дополнительные модули-наполнители) и т. Д., Собирает данные, заполняет их представления, а затем возвращается обратно (и, при необходимости, снова возвращается), пока основное представление не сможетбыть заполненным.

Я создал свой собственный фреймворк HMVC, который делает именно это с моими классами «запросов», основанными на фреймворке Kohana. Эта ссылка на техпортал описывает, как это работает, в подробном, но понятном виде.

Число просмотров

Архитектура ваших представлений (или «страниц») звучит правильно. Я называю их панелями. Итак, используя буферизацию вывода:

  1. Основной контроллер «запрашивает» субконтроллер (с любыми параметрами, переданными ему, если требуется) с ответом субконтроллеров, установленным в переменную. Например:

     // Create a new request to a controller.
$request = RequestFactory::createRequest();
$request->controller('modules/customers/customers/controllers/CustomersController@showAllAddEditDelete');
$currentCustomers = $request->execute();

  2. Субконтроллер собирает любые необходимые данные, отображает их в подкачке и возвращает.

     // Instantiate the view object.
$view = new View();

// Instantiate the customers model.
$customersModel = new CustomersModel();

// Set the data.
$view->data('customers', $customersModel->getCustomers(), false);

// Set the template.
$view->template('modules/customers/customers/views/show_add_edit_delete');

return $view->render(false);

  3. Затем основной контроллер подготавливает свои данные и отображает их представление.

     // Instantiate the view object.
$view = new View();

// Set the panels.
$view->data('panel_1', $currentCustomers, false);

// Set the panels layout.
$view->partial('panels', 'views/html/secure/templates/panels/layout_2');

// Set the template.
$view->template('views/html/secure/templates/application.php');

// Render the page.
$view->render();

Этот процесс может быть настолько глубоким (вложенным), насколько вам нужно.

Надеюсь, это поможет.