Реферат по программированию на тему Шаблоны архитектуры корпоративных приложений

Введение

При обсуждении способов проектирования корпоративных приложений и вариантов выбора типовых решений важно понимать, что двух одинаковых приложений просто не существует и различия в проблемах обусловливают необходимость применения различных средств достижения поставленных целей. Отметим, что возникает проблема: выбор решения для проектирования не оказывает одинакового влияния на факторы эффективности.
Основа типового решения состоит в том, что подход достаточно общий и эффективен для преодоления периодически возникающих проблем определенного рода. Типовые решения можно воспринимать и как рекомендации: создание типов предполагает вычленение и кристаллизацию таких относительно независимых рекомендаций, что позволяет использовать его более или менее обособленным образом.

1. «Расслоение» системы
1.1 Развитие модели слоёв в корпоративных программных приложениях

Модель слоев является одной из моделей обсуждения, используемой разработчиками ПО, чтобы разделить сложные системы на более простые части. Например, в архитектуре компьютерных систем различаются слои кодов на языке программы, функции операционных систем, драйверы устройств, наборы инструкций центра процессора, внутренняя логика чипов. В сетевых средах протокол FTP основывается на протоколе TCP, который, в свою очередь, работает «поверх» протокола IP, расположенного в Ethernet.
Описывая систему в терминах архитектурных слоёв, удобно воспринимать составляющие её подсистемы в виде «слоёного пирога». Слой более высокого уровня пользуется службами, представляемыми нижележащим слоем, но тот не «осведомлён» о наличии соседнего верхнего слоя. Не каждая архитектура так «непроницаема», но чаще всего это так.
Расчленение системы на слои предоставляет целый ряд преимуществ:
• Отдельный слой можно рассматривать как единый самодостаточный комплекс, не особо беспокоясь о наличии иных слоев, например, для того чтобы создать службу FTP нужно знать протокол TCP, а не Ethernet тонкости. Можно выбрать альтернативный вариант реализации базовых слоев приложений FTP, которые могут работать без изменений в Ethernet-среде, в PPP-соединении или в любую другую среду передачи данных.
• Наличие слоев можно сделать минимальным. Поэтому, если вы измените среду обмена данными, сохраняя функциональность IP слоя, служба FTP продолжит работу как и раньше. Все слои являются удачными кандидатами на стандартизацию, например, стандарты TCP/IP, которые определяют особенности работы соответствующих слоев системы сетевой коммуникации.
Схема расслоения обладает и определёнными недостатками:
• Слои могут успешно инкапсулировать многие вещи, но не все: модификация слоя сразу связана с необходимостью внесения в другие слои каскадных модификаций. Типичные примеры из области корпоративных приложений: Добавленные поля таблицы данных должны воспроизводиться в графическом интерфейсе и находить соответствующие изображения в каждой строке.
• Небольшие слои нередко снижают производительность системы. При переходе от слоя к слою моделируемые объекты обычно становятся одним представлением в другом. Хотя инкапсулировать нижележащие функции, инкапсулировать нижележащие функции зачастую дает очень существенное преимущество. К примеру, оптимизация транзакций, как правило, приводит к увеличению производительности всего вышеуказанного слоя. Однако самое сложное при использовании архитектурных слоев - определение составляющих и границ ответственности каждого слоя.

1.2 Три основных слоя

Внимание акцентируется на архитектуре с тремя основными слоями: представление, домен и источники данных.
Слой представления охватывает всё, что имеет отношение к общению пользователя с системой. Он может быть настолько простым, как и командная строка или текстовое меню, но сегодня пользователю, вероятнее всего, придётся иметь дело с графическим интерфейсом, оформленным в стиле толстого клиента (Windows, Swing и т.п.) или основанным на HTML. К главным функциям слоя представления относится отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте домена (бизнес-логики) и источника данных.
Источник данных – это подмножество функций, обеспечивающих взаимодействие со сторонними системами, которые выполняют задания в интересах приложения. Код этой категории отвечает за контроль трафика, контроль за другими приложениями, передачу информации и т.д. Основной логикой источника данного источника выступает код СУБД большинства корпоративных приложений. Логика домена описывает основную функцию приложения, которая направлена на достижение поставленной цели.
Такие функции относятся к вычислению на базе вводимой и хранимой информации, проверке всех компонентов данных, обработке команд, которые поступают из слоя представлений, и передаче информации слою исходной информации.

1.3 Где должны функционировать слои

В большинстве случаев имеет смысл только два способа размещения и выполнения компонентов корпоративного приложения – на персональном компьютере и сервере корпоративного приложения. Зачастую самое простое - функционирование кода всех слоев системы на серверах. Это может быть возможным, к примеру, если использовать HTML-интерфейс, воплощенный в браузере Основное преимущество того, что все части приложения сосредоточены в едином месте, заключается в том, что в этом случае максимально упрощены процедуры корректировки ошибок, обновления версий. В этом случае не стоит беспокоиться о внесении соответствующих изменений в все компьютеры для совместимости с другими программами и синхронизации с серверными компонентами. Общая точка зрения о возможности размещения каких-либо слоев на компьютере клиента заключается в улучшении быстроты реагирования приложения и обеспечении локального функционирования приложений. Чтобы код сервера смог отреагировать на действия, предпринимаемые пользователем на клиентской машине, требуется определённое время. И если пользователь нуждается в быстром опробовании нескольких вариантов, и сразу же увидит результат, то длительность обмена становится серьезным препятствием.
Принимая во внимание все приведенные точки зрения, вы можете исследовать алгоритмы, посмотрев слой на слой. Лучше всегда на сервере располагать слои источников данных. Исключение составит случай дублирования функций сервера в коде «очень толстого» клиента, чтобы обеспечить средства локальной работы системы. В этом случае предполагается синхронизация изменений в раздельных источниках данных клиентской машины и сервера.
Решение о том, где должен функционировать интерфейс панели представления, в основном зависит от типа пользовательского интерфейса. Применение толстого клиентского интерфейса автоматически приводит к необходимости размещения на машине клиента слоя представлений. Использование веб-интерфейса говорит о том, что логическое представление сосредоточено на серверах. Есть исключения, такие как удаленное управление клиентской программой с запуском веб-сервера для персонального компьютера, но такое встречается редко.