MVC / HMVC и объектно-ориентированное программирование - PullRequest
1 голос
/ 05 августа 2010

Я читал и узнавал об объектно-ориентированном программировании ( Head First Объектно-ориентированный анализ и проектирование и Код завершен: практическое руководство по созданию программного обеспечения - благодаря предложениямнайдено на StackOverflow).Я также изучал, как использовать пару сред PHP MVC (в частности, Codeigniter и Kohana ).

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

Предположение № 1:

Если подумать о правильной абстракции для веб-приложения, каталог, содержащий библиотеку классов, должен располагаться вне каталога, содержащего файлы презентации.,Эта организация придерживается принципа СУХОЙ («Не повторяйся»), который позволяет нескольким папкам презентаций (www.domain.com, management.domain.com, api.domain.com и т. Д.) Работать с одними и теми же объектами.

Предположение № 2:

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

Предположение № 3:

Если инфраструктура MVC является просто классом представления, то класс базы данных, который инициализирует экземпляр контроллера, нарушает абстракцию класса контроллера.Модель (экземпляра контроллера) не должна иметь («имеет») базу данных, у нее должна быть вещь (пользователь, продукт) из библиотеки классов, и у этой вещи должна быть база данных.

Предположение # 4:

Более того, если инфраструктура MVC является просто классом представления, класс базы данных, который инициализирует экземпляр контроллера, слишком тесно связан с классом контроллера.Переход от одного метода хранения к другому требует перефакторинга всех моделей.

Предположение № 5:

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

ОБНОВЛЕНИЕ:

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

Для модели не должно быть:

$user = new User($id);
$data['name'] = $user->getName();
$data['title'] = $user->getTitle();
return $data

Вместо:

$query = $this->db->get_where('user', array('id' => $id), 1, 0);
$row = $query->row_array(); 
$data['name'] = $row['name'];
$data['title'] = $row['title'];
return $data

Ответы [ 2 ]

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

Предположение № 1: Думая о правильной абстракции для сети приложение, каталог, содержащий библиотека классов должна быть находится за пределами каталога содержащие файлы презентаций. Эта организация придерживается СУХОЙ («Не повторяй себя») с учетом нескольких презентаций папки (www.domain.com, management.domain.com, api.domain.com, и т. д.) для работы с одинаковыми объектами.

Это правильно в том смысле, что библиотеки не используются для представления (т.е. не представления). Это модули, которые будут использоваться на нескольких контроллерах. Обычно они не должны использовать постоянные данные, поскольку они не являются моделями, но в некоторых случаях используют (например, сеансы codeigniter).

Предположение № 2:

Если все ваши классы расположены за пределами ваших папок презентации, тогда модели в вашем MVC реализация просто использовать экземпляры эти классы. Если это правда, то рамки MVC это просто презентационный класс (контроллер) это помогает управлять вводом (GET & POST-запросы), ответ (модели или экземпляры) и вывод (просмотры или шаблоны).

Это немного смущает меня. Вы правы, контроллер просто используется для оркестровки запросов GET и POST, но будьте осторожны при вызове «класса представления». контроллер отвечает за оркестровку моделей (постоянные данные) и представлений (представление данных).

Предположение № 3:

Если инфраструктура MVC является просто класс презентации, затем база данных класс, который экземпляр контроллера инициализирует ломает абстракцию класс контроллера. Модель (из экземпляр контроллера) не должен иметь («имеет»), она должна иметь вещь (пользователь, продукт) из библиотеки классов и эта вещь должна иметь база данных.

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

Предположение № 4:

Кроме того, если инфраструктура MVC просто презентационный класс, класс базы данных, что контроллер экземпляр инициализируется слишком тесно в сочетании с контроллером класса. Переход от одного метода хранения к другой требует перефакторинга всего модели.

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

Предположение № 5:

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

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

0 голосов
/ 10 августа 2010

ОБНОВЛЕНИЕ: Просто хотел ответить / прокомментировать мой запутанный вопрос.

Кохана предоставляет папку с модулями, в которой рассматриваются мои предыдущие проблемы.

Например, если вы настроите домен с поддоменом с помощью Plesk, структура папок будет следующей.

httpdocs
subdomains
+--management
   +--httpdocs

Если вы хотите разделить код между доменом и поддоменом, используя Kohanaмодули, вы можете настроить свою файловую систему следующим образом:

modules
system
httpdocs
+--application
+--index.php
subdomains
+--management
   +--httpdocs
      +--application
      +--index.php

Где httpdocs / index.php и поддоменов / management / httpdocs / index.php имеетследующее:

$application = 'application';
$modules = '/root/pathto/modules';
$system = '/root/pathto/system';

Любые объекты, которые используются как в домене, так и на поддомене, могут быть помещены в папку модулей для использования приложением.

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

...