Подход GUI компонента MVC - PullRequest
       11

Подход GUI компонента MVC

4 голосов
/ 24 марта 2012

Меня интересует общий подход к созданию интерактивного графического интерфейса с использованием MVC3.

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

Каждый Компонент ДОЛЖЕН иметь свое собственное определение модели, контроллер и представления. Компонент инкапсулирует не только представление, но и поведение через свой контроллер.

Все внутренние детали реализации, модель, поведение и т. Д. Должны находиться внутри компонента, так что компонент становится независимым, модульным - черным ящиком. Это позволяет компоненту быть измененным, не нарушая ничего в контексте, в котором компонент используется.

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

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

Наконец, компонент должен предоставлять механизм для «общения» или «взаимодействия» с внешним миром. Помимо внутренних компонентов, компонент должен предоставлять некий «внешний» интерфейс (например, параметры, данные, функции, события и т. Д.), Который позволял бы интегрировать компонент в контекст выполнения.

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

Реальный мир Компонент категорий пример:

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

Реальный мир Компонент продуктов пример:

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

Реальный Страница панели инструментов (контекст, сценарий) пример:

На странице отображаются компоненты категорий и продуктов. Компонент «Продукты» отображает все продукты для выбранной в данный момент категории и, следовательно, должен предоставлять внешний интерфейс (параметр или что-то еще) для получения идентификатора выбранной категории из контекста. Компонент категорий должен обеспечивать некоторый внешний интерфейс, чтобы контекст мог действовать при изменении выбранной категории и предоставлять идентификатор выбранной категории для компонента продуктов.

Технически, коммуникационный подход для обновления страницы в основном проходил бы через AJAX, но если это возможно без AJAX, было бы еще лучше.

В случае AJAX, я хотел бы решение, которое использует контроллер (ы) на стороне сервера, который решает и отображает то, что должно быть обновлено на клиенте (JSON или что-то).

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

Важно: Не обязательно, чтобы компоненты работали при непосредственном вызове по какому-либо маршруту.

Как бы вы вообще реализовали описанную систему?

Ответы [ 3 ]

4 голосов
/ 23 мая 2012

Я думаю, вам нужно исследовать реальные проекты и посмотреть, какой подход вам нужен.Попробуйте следующий проект, и вы сможете найти много лучших практик:

Здесь вы можете найти реализацию мер безопасности, сервисов, аутентификации и многое другое.

Kigg
http://www.nopcommerce.com/downloads.aspx
http://orchard.codeplex.com/

Мне трудно сказать, как это должно быть реализовано.Лучше закодировать это.Но использование инъекции зависимостей представлений, контроллеров, служб и репозиториев обязательно в вашем случае.

1 голос
/ 29 мая 2012

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

Вы можете создавать черные ящики, состоящие из контроллеров и представлений, только если каждый из них отвечает за весь шаблон взаимодействия пользователя с машиной. Это «большие компоненты», а не маленькие строительные блоки, как в случае реализации CMS.

Orchard CMS использует аналогичный подход . Однако то, что вы называете компонентами, на самом деле является заранее заданными блоками, которые играют роль целых разделов веб-сайтов, создаваемых пользователем.

1 голос
/ 28 мая 2012

Мне кажется, что вы пытаетесь достичь чего-то, что может быть несовместимо с философией web MVC (другие реализации MVC могут это поддерживать).

Однако, если вы хотите заняться написанием фреймворка поверх ASP MVC, я уверен, что вы могли бы добиться того, чего хотите. Например, используя Areas, вы можете достичь формы инкапсуляции ваших контроллеров, моделей представлений и представлений.

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

Вы можете добиться большего пробега, используя клиентскую среду, такую ​​как Backbone.js, поверх ASP MVC.

...