Начиная с разработкой программного обеспечения с помощью MVC, OO и [закрытых] Шаблонов разработки

Примечание: Этот вопрос был обновлен для обеспечения большего количества детали и понимания, чем ранее.

ОБНОВЛЕНИЕ: Я просто хочу сказать спасибо всем, кто ответил. Я все еще в значительной степени в темноте по поводу того, какой шаблон разработки работал бы лучше всего на Виджет. Возможно, один из шаблонов Фабрики или Разработчика?

Я просто начинаю на новом проекте и потребности использовать MVC, OO и шаблоны разработки.

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

Высокоуровневые требования

• страница, которая отображает ряд (только HTML) виджеты.
• данные виджета будут базироваться от запроса базы данных.
• страница может использоваться для просмотра отдельных наборов данных, содержащих столь же размеченные данные. Например, единственная страница отобразит виджеты, которые сообщают относительно различных аспектов производительности единственного студента.
• хочу видеть производительность другого студента, потянуть другую страницу. Отображение различных виджетов для различных студентов не нужно (хотя может быть хорошо иметь позже).
• Могут быть многие студенты, но данные, содержавшиеся в базе данных, так же размечаются для всех студентов.
• путем виджет отображен, может быть изменен легко (скажите что изменение виджета от отображения как круговая диаграмма для отображения как столбиковая диаграмма).
• виджеты должны быть в состоянии быть созданными быстро.

Низкоуровневые требования

• В настоящее время данные не изменяются так, виджеты не должны будут автоматически обновлять себя.
• Виджеты могут представить отношение двух вещей (например, отношение проваленных тестов к успешным тестам как круговая диаграмма), серия точек или иногда единственное числовое значение.
• Разработка новых виджетов должна быть бризом, существующий код не должен быть изменен.
• Платформа, которая будет использоваться: Платформа Зенда, на основе MVC.

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

Вот передача при разрушении обязанностей каждого слоя MVC:

Посмотреть: Представления зенда являются шаблонами HTML с введенным PHP. Они будут содержать один из нескольких типов виджетов. Виджеты имеют различные формы включая: статические изображения JPEG (загруженный из удаленного сайта т.е.: <img src="http://widgetssite.com?x=2&y=3"/>, JSON основывал виджеты JavaScript или диаграммы различных видов (круговая диаграмма, столбиковая диаграмма и т.д.)

Контроллер: Создает виджеты, присваивает их представлению впоследствии. Набор виджетов, который должен быть отображен на странице, должен сохраняться где-нибудь. Так как я не могу думать о хорошем способе сделать это в представлении, я добавлю это к обязанностям по контроллерам на данный момент. Если существует лучшее место для этого, кричите. Контроллер должен будет также обработать любые другие входные параметры и передачу их к виджету. Например, data_set идентификатор, который может быть передан в строке URL как http:/.../report/?student_id=42

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

Некоторые точки:

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

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

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

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

   Вот первая передача в довольно простом классе для Виджета:

   class Widget{ 
     //method called by the view 
     render() {//output the markup based on the widget Type and interleaved the processed data} 
   
     //methods called by the controller: 
     public function __construct() {//recieve arguments for widget type (query and renderer), call create()}  
     public function create() {//tell the widget to build the query, execute it, and filter the data} 
     public function process_data() {//transform into JSON, an html entity etc} 
   
     //methods called by the model: 
     public function build_query() {...}; 
     public function execute_query() {...}; 
     public function filter_data() {...}; 
   } 
   

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

4. Например, это просто для передачи виджета, который был создан в контроллере к Представлению для рендеринга.

   Но когда дело доходит до реализации модели это кажется не таким образом прямым. Шаблон Шлюза таблицы более прост реализовать, чем ORM. Но так как шаблон шлюза таблицы имеет один класс для каждой модели/таблицы, это, кажется, не отвечает всем требованиям. Я мог создать модель для конкретной таблицы, и затем в этом, инстанцировать любых других необходимых моделей. Но это, кажется, так не соответствует Шаблону Шлюза Таблицы, а скорее шаблону ORM. Шаблон Шлюза Таблицы может быть реализован с несколькими таблицами? Что альтернативы там? Это имеет смысл, что контроллер создает виджет, и виджет создает Модель?

5. Другая проблема, которая возникает, - то, что этот дизайн не включает простоту создания виджета. т.е. Скажите, что я хотел создать PiechartWidget, сколько кода может быть снова использовано? Разве не имело бы большего количества смысла использовать некоторые идеи OO, такие как интерфейс или абстрактные классы/методы и наследование?

   Скажем, я абстрагирую класс Виджета поэтому, только общие методы определяются конкретно, и остальные объявляются как абстрактные методы. Пересмотр класса Виджета для создания этого абстрактным (вторая передача):

   abstract class Widget{
   
     private $_type;
     private $_renderer;
   
     //methods called by the controller:
     //receive arguments for widget type (query and renderer), 
     protected function __construct($type, $renderer) {
       $this->_type = $type;
       $this->_render = $renderer;
       $this->create();
      } 
   
     //tell the widget to build the query, execute it, and filter the data
     private function create() {
       $this->build_query();
       $this->execute_query();
       $this->filter_data();
     }
   
     //methods called by the model:
     abstract protected function build_query();
   
     protected function execute_query() {
       //common method
     }
   
     abstract protected function filter_data();
   
     //method called by controller to tranform data for view
     //transform into JSON, an html entity etc
     abstract protected function process_data();
   
     //method called by the view
     //output the markup based on the widget Type and interleave the processed data
     abstract protected function render(); 
   }
   

   Действительно ли это - хороший дизайн? Как это могло быть улучшено?

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

Я надеюсь, что любой мог обеспечить по крайней мере некоторую обратную связь на этом дизайне. Проверить его? Разорвите его. Назовите меня идиотом. Это прекрасно также. Я мог использовать, любой передает тягу.

Несколько конкретных вопросов:

Q1. Что лучший способ состоит в том, чтобы реализовать рендереры как часть класса Виджета или как отдельный класс? 1a. Если бы отдельный, как это взаимодействовало бы с классом (классами) виджета?

Q2. Как я мог улучшить этот дизайн для упрощения создания новых видов виджетов?

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