Модульная конструкция Модульная конструкция является общепризнанным положительным моментом в разработке программного обеспечения. Как и в науке в целом, разбить проблему на более мелкие кусочки размером с кусочек облегчает решение. Это также позволяет разным людям решать разные части проблемы, и в конечном итоге все работает правильно. Каждый компонент тогда самодостаточен и, пока интерфейс между различными компонентами остается постоянным, может быть расширен или даже потрошен и переписан по мере необходимости, не вызывая хаотического беспорядка.
Я должен отметить, что модульная конструкция нето же самое, что и дизайн на основе плагинов, который используют многие проекты с открытым исходным кодом. «Модули» Drupal на самом деле являются плагинами. Ядро Linux, Apache, Eclipse и многие другие громкие проекты с «загружаемыми модулями» являются архитектурами на основе плагинов. Архитектуры на основе плагинов не являются несовместимыми с модульным дизайном и на самом деле хорошо дополняют его, но я отступаю ...
Большинство программных архитектурных шаблонов основаны на идее, что модульный дизайн - это хорошая вещь, скорее по определению. Существует множество архитектурных шаблонов для систем в зависимости от того, что они должны делать. Для интерактивных систем обычная разбивка компонентов - это «компонент дисплея», «компонент хранения данных» и «бизнес-логика».
MVC Наиболее широко известной архитектурой интерактивной системы является Model-View-Controller, илиMVC. Большинство хороших настольных приложений используют MVC или его вариант, иногда с контроллером, частично объединенным с View. В MVC, как показывает симпатичная картинка на другом конце этих ссылок, модель содержит данные, представление - это та часть, которую видит пользователь, а контроллер - посредник для бизнес-логики. Кажется разумным, верно? Теперь рассмотрим подробнее.
В MVC компонент View имеет прямой доступ к модели. Контроллер сам не вводит изображение, если нет фактического изменения данных. Простое чтение и отображение данных полностью выполняется самим компонентом View. В результате система может иметь сразу несколько активных компонентов View, все из которых читают и отображают данные различными способами, даже в разных системах, на разных языках или в разных режимах (графический интерфейс или текстовый или веб-интерфейс). С другой стороны, это означает, что компонент View должен иметь довольно сложную логику. Он должен знать, как извлекать данные из Модели, а это значит, что он должен знать, какова структура данных (или, по крайней мере, богатый API перед Моделью). Он должен уметь обрабатывать взаимодействие с самим пользователем с помощью своего собственного цикла обработки событий.
Что ж, это исключает большинство возможных установок Web-MVC. Один из самых распространенных криков таких систем - «убрать вещи из базы данных из HTML». Вместо этого все обрабатывается через интеллектуальный контроллер, который использует слой шаблона для рендеринга и отображения вывода. Это не плохой дизайн обязательно, но это не MVC. Если компонент дисплея не имеет прямого, произвольного доступа или доступа к хранилищу данных, то это не MVC.
PAC Менее известной, но все еще широко используемой архитектурой является Presentation-Abstraction-Control, илитихоокеанскийДва основных различия между MVC и PAC заключаются в том, что в PAC компонент Presentation является «тупым», в то время как весь интеллект находится в контроллере, а PAC является многоуровневым. Опять же, смотрите красивую картинку.
Вы заметите, что компоненты Presentation и Abstraction никогда не общаются друг с другом. Контроллер принимает ввод, а не компонент отображения. Контроллер имеет всю бизнес-логику и информацию о маршрутизации. Компонент Presentation - это, по сути, просто фильтр, который принимает необработанные данные, которые Контроллер проталкивает через них, и отображает их в HTML (или WML, или XML, или текст, или значок в графической системе мониторинга, или как угодно). Это просто система шаблонов.
Классическим примером архитектуры PAC является система управления воздушным движением. Один агент PAC получает данные от радарной системы о местонахождении входящего 747 и использует компонент Presentation для рисования изображения этого сообщения на холсте (экране). Другой агент самостоятельно получает информацию о взлетевшем DC-10 и рисует, что всплывает на холсте. Еще один получает данные о погоде и рисует облака, в то время как другой отслеживает приближающийся вражеский бомбардировщик и вместо этого рисует красную вспышку. (Э-э, подождите ...)