Remkomplekty.ru

IT Новости из мира ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Архитектура корпоративных приложений

Software Design

Популярно о проектировании программ

Обо мне

Ярлыки

  • .net (1)
  • архитектура (4)
  • литература (2)
  • маркетинг (4)
  • планирование (4)
  • проектирование (14)
  • собеседование (4)
  • требования (8)
  • триз (2)
  • управление проектами (12)
  • Фаулер (2)
  • функциональный анализ (13)
  • халтура (1)
  • эргономика (5)
  • c# (1)
  • concept (2)
  • estimate (5)
  • ITGM (1)
  • singularity (1)
  • SPM Club (2)
  • usability (5)
  • use-case (2)

понедельник, 5 декабря 2011 г.

Отзыв на книгу Фаулера «Архитектура корпоративных приложений»

9 комментариев:

Отцов не уважаете. 🙂 Постыдитесь. :)))
А вообще, если по делу, в некоторых местах Фаулер говорит, как оракул, двояко. Из-за этого и возникают противоречия.

Наоборот, Фаулера уважаю. Просто честно отметил, как достоинства, так и недостатки. Конечно, с моей точки зрения.

1) Про объем — авторы книг получают деньги за объем. Поэтому почти в каждой книге плотность информации очень низкая, особенно в книгах по архитектуре.
2) Про содержание — Фаулер не автор этих паттернов, он лишь популяризатор, для него «шлюз таблицы» примерно на одном уровне с «active record» находится.

К сожалению большинство книг по архитектуре пишутся именно так.

У меня есть книга «Архитектурное проектирование жилых зданий». Как-то незаметно, чтобы авторы старались раздуть объём. Наоборот, мне кажется, они постарались вместить больше информации в меньший объём.

Странно, почему в книгах, посвящённых software architecture это не так?

>Книга не содержит описания архитектур, хотя в названии используется слово «архитектура».

А можно поинтересоваться у автора, что подразумевается под «описанием архитектуры» и какая книга такие описания содержит.

2 Анонимный: Чтобы понять, как на самом деле должна быть организована книжка по архитектуре, достаточно открыть книгу по проектированию зданий, самолетов или каких-либо других систем, методология проектирования которых устоялась, и взглянуть на оглавление.

Пример. Оглавление книги «Архитектурное проектирование жилых зданий»:

Глава 1. Общие сведения о жилище.
1.1. Жилая среда как объект проектирования.
1.2. Основные типы жилых зданий.
1.3. Виды жилой застройки.

Глава 2. Основные факторы, влияющие на проектирование жилища.
2.1. Социальные требования к жилищу.
2.2. Демография населения и структура жилого фонда.
2.3. Эстетика жилища.
2.4. .

Глава 3. Методика проектирования.
3.1. Предпроектный анализ.
3.2. Комплексная разработка проектов.
3.3. .

Глава 4. Функциональные основы формирования квартир.
4.1. .

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

При всем моем уважении к Мартину Фаулеру. Его книга вовсе не образец книги по архитектура ПО. Кроме того. в книге дается явное ограничение: корпоративные приложения, т.е. типовые решения в исторической ретроспективе именно для бизнес-приложений. Понятию архитектура в ней посвящено три абзаца. Кроме того оригинальное название звучит совершенно иначе, чем русский вариант. Это уже маркетинговый ход Вильямс.

Если говорит об книгах о архитектуре, то следует в первую очередь смотреть хотя бы Басса.
А еще лучше — http://www.viewpoints-and-perspectives.info

Далее использования концепция понятия архитектура материаьных объектов для критики несостоятельности описания архитектур мысленных объектов, плагаю некорректным

1. понятие архитектуры — http://ru.wikipedia.org/wiki/%C0%F0%F5%E8%F2%E5%EA%F2%F3%F0%E0 — Очевидно, что за сотни тысяч лет человечество действительно научилось делать это и как искусство и превратило в точную науку.

2. вы же сами ранее определили архитектуру как список функций (в ответе на мой комментарий). Однако обратите внимание на содержательную часть цитируемого вами оглавления: среди факторов функциональные факторы недоминантные.

Эдуард, по названию согласен. В оригинале книга называется «Patterns of Enterprise Application Architecture». Тем не менее, я не отказываюсь от своей точки зрения — книге действительно не хватает системности.

По поводу «архитектуры как списка функций». По-моему, мы тогда говорили о функциональной архитектуре. Плюс этот отзыв был написан 5 лет назад.

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

Мартин Фаулер: Шаблоны корпоративных приложений

Patterns of Enterprise Application Architecture

Мы пришлем письмо о полученном бонусе, как только кто-то воспользуется вашей подборкой. Проверить баланс всегда можно в «Личном пространстве»

Мы пришлем письмо о полученном бонусе, как только кто-то воспользуется вашей ссылкой. Проверить баланс всегда можно в «Личном пространстве»

Аннотация к книге «Шаблоны корпоративных приложений»

Создание компьютерных систем — дело далеко не простое. По мере того как возрастает их сложность, процессы конструирования соответствующего программного обеспечения становятся все более трудоемкими, причем затраты труда растут экспоненциально. Как и в любой профессии, прогресс в программировании достигается исключительно путем обучения, причем не только на ошибках, но и на удачах — как своих, так и чужих. Книга дает ответы на трудные вопросы, с которыми приходится сталкиваться всем разработчикам корпоративных систем. Автор, известный специалист в области объектно-ориентированного программирования, заметил, что с развитием технологий базовые принципы проектирования и решения общих проблем остаются неизменными, и выделил более 40 наиболее употребительных подходов, оформив их в виде типовых решений. Результат перед вами — незаменимое руководство по архитектуре программных систем для любой корпоративной платформы. Это своеобразное учебное пособие поможет вам не только усвоить информацию.

Создание компьютерных систем — дело далеко не простое. По мере того как возрастает их сложность, процессы конструирования соответствующего программного обеспечения становятся все более трудоемкими, причем затраты труда растут экспоненциально. Как и в любой профессии, прогресс в программировании достигается исключительно путем обучения, причем не только на ошибках, но и на удачах — как своих, так и чужих. Книга дает ответы на трудные вопросы, с которыми приходится сталкиваться всем разработчикам корпоративных систем. Автор, известный специалист в области объектно-ориентированного программирования, заметил, что с развитием технологий базовые принципы проектирования и решения общих проблем остаются неизменными, и выделил более 40 наиболее употребительных подходов, оформив их в виде типовых решений. Результат перед вами — незаменимое руководство по архитектуре программных систем для любой корпоративной платформы. Это своеобразное учебное пособие поможет вам не только усвоить информацию, но и передать полученные знания окружающим значительно быстрее и эффективнее, чем это удавалось автору. Книга предназначена для программистов, проектировщиков и архитекторов, которые занимаются созданием корпоративных приложений и стремятся повысить качество принимаемых стратегических решений.

Краткий обзор 10 популярных архитектурных шаблонов приложений

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

Что такое архитектурный шаблон?

По материалам Википедии,

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

Читать еще:  Архитектура аппаратных средств

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

1. Многоуровневый шаблон

2. Клиент-серверный шаблон

3. Ведущий-ведомый

4. Каналы и фильтры

5. Шаблон посредника

6. Одноранговый шаблон

7. Шина событий

8. Модель-представление-контроллер

9. Доска

10. Интерпретатор

1. Многоуровневый шаблон

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

Чаще всего в общих информационных системах встречаются следующие 4 слоя:

· Слой представления (также известен как слой пользовательского интерфейса)

· Слой приложения (также известен как слой сервиса)

· Слой бизнес-логики (также известен как уровень предметной области)

· Слой доступа к данным (также известен как уровень хранения данных)

Использование

· Общие десктопные приложения.

2. Клиент-серверный шаблон

Данный шаблон состоит из двух частей: сервера и множества клиентов. Серверный компонент предоставляет службы клиентским компонентам. Клиенты запрашивают услуги у сервера, а он, в свою очередь, оказывает эти самые услуги клиентам. Более того, сервер продолжает «подслушивать» клиентские запросы.

Использование

· Онлайн приложения (электронная почта, совместный доступ к документам, банковские услуги).

3. Ведущий-ведомый

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

Использование

· В репликации баз данных. Там главная БД считается авторитетным источником, а подчиненные базы с ней синхронизируются.

· Периферийные устройства, подключенные к шине в компьютере (ведущие и ведомые устройства).

4. Каналы и фильтры

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

Использование

· Компиляторы. Последовательные фильтры выполняют лексический, синтаксический, семантический анализ и создание кода.

· Рабочие процессы в биоинформатике.

5. Шаблон посредника

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

Сервер размещает свои возможности (службы и характеристики) у посредника (брокера). Клиент запрашивает услугу у брокера. Затем брокер перенаправляет клиента к подходящей службе из своего реестра.

Использование

6. Одноранговый шаблон

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

Использование

· Проприетарные мультимедийные приложения (как тот же Spotify).

7. Шина событий

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

Использование

· Разработки на Android

8. Модель-представление-контроллер

Этот шаблон также известен как MVC-шаблон. Он разделяет интерактивные прикладные программы на 3 части:

1. модель — содержит ключевые данные и функционал;

2. представление — показывает информацию пользователю (можно задавать более одного представления);

3. контроллер — занимается обработкой данных от пользователя.

Это делается с целью разграничения внутреннего представления информации от способов ее представления и принятия от пользователя. Данная схема изолирует компоненты и позволяет эффективно реализовать повторное использование кода.

Использование

· Архитектура WWW-приложений, написанных на основных языках программирования.

9. Доска

Такой шаблон подходит для проблем, для которых отсутствуют четкие детерминированные решения. Шаблон «Доска» состоит из 3 главных компонентов:

· доска — это структурированная глобальная память, содержащая объекты из пространства возможных решений;

· источник знания — специализированные модули со своим собственным представлением;

· компоненты управления — выбирает, настраивает и исполняет модули.

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

Использование

· идентификация и отслеживание транспортных средств;

· определение структур белка;

· интерпретация сигналов Sonar.

10. Интерпретатор

Он подходит для разработки компонента, который должен интерпретировать программы, написанные на специальном языке программирования. В основном, там расписано, как вычислять строки (иначе говоря: «предложения» или «выражения»), написанные на каком-то определенном языке программирования. Суть в том, чтобы присвоить класс каждому символу языка.

Использование

· языки запросов к базе данных (SQL);

· языки, которые используются для описания протоколов передачи данных.

Сравнение архитектурных шаблонов

Ниже приводятся плюсы и минусы каждого из архитектурных шаблонов.

Многоуровневый шаблон

Плюсы:

  • Одним низким слоем могут пользоваться разные слои более высокого ранга.
  • Слои упрощают стандартизацию, т.к. мы четко определяем уровни.
  • Изменения вносятся внутри какого-то одного слоя, при этом остальные слои остаются неизменными.

Минусы:

  • Не универсален.
  • В ряде ситуаций возможен пропуск некоторых слоев.

Клиент-серверный шаблон

Плюсы:

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

Минусы:

  • Запросы обычно выполняются в отдельных потоках на сервере.
  • Взаимодействие между процессами повышает ресурсозатратность, т.к. разные клиенты имеют разное представление.

Шаблон «Ведущий-ведомый»

Плюсы:

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

Минусы:

  • Все ведомые изолированы, у них отсутствует общее состояние.
  • Период ожидания в коммуникации «ведущий-ведомый» — это значительный минус. Например, в системах реального времени.
  • Подходит только для тех проблем, решение которых можно разложить на части.

Шаблон «Каналы и фильтры»

Плюсы:

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

Минусы:

  • Эффективность снижается из-за самых медленных процессов фильтрации. При переходе от одного фильтра к другому выполняется трансформация данных, которая ведет к повышенному потреблению ресурсов.

Шаблон «Посредник»

Плюсы:

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

Минусы:

  • Необходима стандартизация описаний служб.

Одноранговый шаблон

Плюсы:

  • Поддерживает децентрализованные вычисления. Крайне устойчив к сбоям в любом узле.
  • Высокая масштабируемость по части ресурсной и вычислительной мощности.

Минусы:

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

Шаблон «Шина событий»

Плюсы:

  • Простое добавление новых подписчиков, издателей и связей. Хорошо зарекомендовал себя для сильно распределенных приложений.

Минусы:

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

Шаблон «Модель-представление-контроллер»

Плюсы:

  • Упрощает создание различных представлений одной и той же модели; их можно включить или отключить на этапе выполнения.

Минусы:

  • Возрастает сложность алгоритма. Может привести ко многим ненужным корректировкам действий пользователей.

Шаблон «Доска»

Плюсы:

  • Легкое добавление новых приложений.
  • Можно без труда расширять структуры пространства данных.

Минусы:

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

Шаблон «Интерпретатор»

Плюсы:

  • Возможно высокодинамичное поведение.
  • Отличное решение для конечных пользователей с точки зрения удобства программирования.

Минусы:

  • Проблемы с производительностью, т.к. интерпретированный язык медленнее скомпилированного.

Рецензии на книгу « Архитектура корпоративных программных приложений »

Мартин Фаулер

Создание компьютерных систем — дело далеко не простое. По мере того как возрастает их сложность, процессы конструирования соответствующего программного обеспечения становятся все более трудоемкими, причем затраты труда растут экспоненциально. Как

Лучшая рецензия на книгу

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

Поделитесь своим мнением об этой книге, напишите рецензию!

Рецензии читателей

Мартин Фаулер — имя, которое знакомо любому уважающему себя специалисту в разработке программного обеспечения (ПО) в первую очередь потому, что это человек, который умеет писать легко читающиеся книги про очень полезные в жизни вещи. По сути каждая его книга о разработке ПО стала своего рода классикой и практически обязательна к прочтению начинающими специалистами. Эта книга затрагивает вопросы архитектуры больших и сложных программных систем, ориентированных на бизнес.

Разрабатывать ПО трудно. Разрабатывать сложное ПО невыразимо трудно. Количество “движущихся частей” (уж не говоря о числе их сочетаний) в современных программных системах во много раз превышает количество элементарных конструктивных элементов любых устройств или других материальных объектов, создаваемых человеком. В этом смысле критическим становится понятие архитектуры ПО. Как без чёткого плана и досконального понимания всех процессов нельзя построить многоэтажный дом, так и без грамотного проектирования нельзя создать сложную программную систему. По аналогии со строительством зданий и планированием городов в проектировании ПО с годами стали выделять шаблоны — удачные решения типовых проблем. Самая известная книга в этой области описывает два с половиной десятка такого рода шаблонов проектирования, однако они абстрактны и подходят для решения широкого круга задач. Фаулер же рассматривает проблемы, характерные для создания крупных бизнес-приложений: работа с данными, управление параллельными вычислениями, работа с пользователями, организация веб-приложений, общая организация приложений в виде набора взаимодействующих друг с другом слоёв и т.п.

Книга Фаулера имела интересную судьбу. Проблемы, описанные в ней 15 лет назад, оказались настолько широко распространёнными, а шаблоны насколько удачными, что с годами большая часть из них была воплощена в в библиотеках и технологиях программирования, ставших стандартами де-факто в мире бизнес-приложений. В настоящее время ни один нормальный человек без очень серьёзной на то необходимости не будет реализовывать, например, ORM-слой для работы с базами данных или создавать свою MVC-инфраструктуру для организации работы веб-приложений. Существуют хорошо зарекомендовавшие себя промышленные технологии, которые берут решение подобных задач на себя, оставляя разработчикам беспокойство о более высокоуровневой логике приложений. Но это не значит, что данная книга морально устарела, даже сейчас она сохраняет актуальность как минимум по двум причинам. Во-первых, она наглядно показывает, как устроены внутри распространённые библиотеки и фреймворки, и объясняет, почему они устроены именно так. Ну и во-вторых, что даже более важно, она учит проектировщика думать: анализировать проблему и выбирать варианты её решения в зависимости от параметров создаваемой системы и ограничений, накладываемых на её работу. С образовательной точки зрения важность этого момента сложно переоценить.

Стоит, однако, отметить, что наибольший эффект эта книга окажет на людей, которые уже некоторое время посвятили разработке крупного ПО. Без такого опыта читателю будет довольно непросто понять, зачем нужно городить все эти промежуточные уровни и придумывать архитектурные изыски, когда можно сделать быстрее и проще “напрямую”. Лишь набив собственные шишки, понимаешь, что прямое решение будет актуально только для небольших программ, а с ростом масштаба системы приходится серьёзно вкладываться в подходящую инфраструктуру. А вот как это делать, как раз и рассказывает нам Фаулер.

Мартин Фаулер — имя, которое знакомо любому уважающему себя специалисту в разработке программного обеспечения (ПО) в первую очередь потому, что это человек, который умеет писать легко читающиеся книги про очень полезные в жизни вещи. По сути каждая его книга о разработке ПО стала своего рода классикой и практически обязательна к прочтению начинающими специалистами. Эта книга затрагивает вопросы архитектуры больших и сложных программных систем, ориентированных на бизнес.

Разрабатывать ПО трудно. Разрабатывать сложное ПО невыразимо трудно. Количество “движущихся частей” (уж не говоря о числе их сочетаний) в современных программных системах во много раз превышает количество элементарных конструктивных элементов любых устройств или других материальных объектов, создаваемых человеком. В этом… Развернуть

Краткий обзор 10 популярных архитектурных шаблонов приложений

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

Что такое архитектурный шаблон?

По материалам Википедии,

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

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

1. Многоуровневый шаблон

2. Клиент-серверный шаблон

3. Ведущий-ведомый

4. Каналы и фильтры

5. Шаблон посредника

6. Одноранговый шаблон

7. Шина событий

8. Модель-представление-контроллер

9. Доска

10. Интерпретатор

1. Многоуровневый шаблон

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

Чаще всего в общих информационных системах встречаются следующие 4 слоя:

· Слой представления (также известен как слой пользовательского интерфейса)

Читать еще:  C4996 c ошибка

· Слой приложения (также известен как слой сервиса)

· Слой бизнес-логики (также известен как уровень предметной области)

· Слой доступа к данным (также известен как уровень хранения данных)

Использование

· Общие десктопные приложения.

2. Клиент-серверный шаблон

Данный шаблон состоит из двух частей: сервера и множества клиентов. Серверный компонент предоставляет службы клиентским компонентам. Клиенты запрашивают услуги у сервера, а он, в свою очередь, оказывает эти самые услуги клиентам. Более того, сервер продолжает «подслушивать» клиентские запросы.

Использование

· Онлайн приложения (электронная почта, совместный доступ к документам, банковские услуги).

3. Ведущий-ведомый

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

Использование

· В репликации баз данных. Там главная БД считается авторитетным источником, а подчиненные базы с ней синхронизируются.

· Периферийные устройства, подключенные к шине в компьютере (ведущие и ведомые устройства).

4. Каналы и фильтры

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

Использование

· Компиляторы. Последовательные фильтры выполняют лексический, синтаксический, семантический анализ и создание кода.

· Рабочие процессы в биоинформатике.

5. Шаблон посредника

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

Сервер размещает свои возможности (службы и характеристики) у посредника (брокера). Клиент запрашивает услугу у брокера. Затем брокер перенаправляет клиента к подходящей службе из своего реестра.

Использование

6. Одноранговый шаблон

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

Использование

· Проприетарные мультимедийные приложения (как тот же Spotify).

7. Шина событий

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

Использование

· Разработки на Android

8. Модель-представление-контроллер

Этот шаблон также известен как MVC-шаблон. Он разделяет интерактивные прикладные программы на 3 части:

1. модель — содержит ключевые данные и функционал;

2. представление — показывает информацию пользователю (можно задавать более одного представления);

3. контроллер — занимается обработкой данных от пользователя.

Это делается с целью разграничения внутреннего представления информации от способов ее представления и принятия от пользователя. Данная схема изолирует компоненты и позволяет эффективно реализовать повторное использование кода.

Использование

· Архитектура WWW-приложений, написанных на основных языках программирования.

9. Доска

Такой шаблон подходит для проблем, для которых отсутствуют четкие детерминированные решения. Шаблон «Доска» состоит из 3 главных компонентов:

· доска — это структурированная глобальная память, содержащая объекты из пространства возможных решений;

· источник знания — специализированные модули со своим собственным представлением;

· компоненты управления — выбирает, настраивает и исполняет модули.

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

Использование

· идентификация и отслеживание транспортных средств;

· определение структур белка;

· интерпретация сигналов Sonar.

10. Интерпретатор

Он подходит для разработки компонента, который должен интерпретировать программы, написанные на специальном языке программирования. В основном, там расписано, как вычислять строки (иначе говоря: «предложения» или «выражения»), написанные на каком-то определенном языке программирования. Суть в том, чтобы присвоить класс каждому символу языка.

Использование

· языки запросов к базе данных (SQL);

· языки, которые используются для описания протоколов передачи данных.

Сравнение архитектурных шаблонов

Ниже приводятся плюсы и минусы каждого из архитектурных шаблонов.

Многоуровневый шаблон

Плюсы:

  • Одним низким слоем могут пользоваться разные слои более высокого ранга.
  • Слои упрощают стандартизацию, т.к. мы четко определяем уровни.
  • Изменения вносятся внутри какого-то одного слоя, при этом остальные слои остаются неизменными.

Минусы:

  • Не универсален.
  • В ряде ситуаций возможен пропуск некоторых слоев.

Клиент-серверный шаблон

Плюсы:

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

Минусы:

  • Запросы обычно выполняются в отдельных потоках на сервере.
  • Взаимодействие между процессами повышает ресурсозатратность, т.к. разные клиенты имеют разное представление.

Шаблон «Ведущий-ведомый»

Плюсы:

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

Минусы:

  • Все ведомые изолированы, у них отсутствует общее состояние.
  • Период ожидания в коммуникации «ведущий-ведомый» — это значительный минус. Например, в системах реального времени.
  • Подходит только для тех проблем, решение которых можно разложить на части.

Шаблон «Каналы и фильтры»

Плюсы:

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

Минусы:

  • Эффективность снижается из-за самых медленных процессов фильтрации. При переходе от одного фильтра к другому выполняется трансформация данных, которая ведет к повышенному потреблению ресурсов.

Шаблон «Посредник»

Плюсы:

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

Минусы:

  • Необходима стандартизация описаний служб.

Одноранговый шаблон

Плюсы:

  • Поддерживает децентрализованные вычисления. Крайне устойчив к сбоям в любом узле.
  • Высокая масштабируемость по части ресурсной и вычислительной мощности.

Минусы:

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

Шаблон «Шина событий»

Плюсы:

  • Простое добавление новых подписчиков, издателей и связей. Хорошо зарекомендовал себя для сильно распределенных приложений.

Минусы:

  • Проблема с масштабируемостью, т.к. все сообщения проходят через одну шину событий.

Шаблон «Модель-представление-контроллер»

Плюсы:

  • Упрощает создание различных представлений одной и той же модели; их можно включить или отключить на этапе выполнения.

Минусы:

  • Возрастает сложность алгоритма. Может привести ко многим ненужным корректировкам действий пользователей.

Шаблон «Доска»

Плюсы:

  • Легкое добавление новых приложений.
  • Можно без труда расширять структуры пространства данных.

Минусы:

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

Шаблон «Интерпретатор»

Плюсы:

  • Возможно высокодинамичное поведение.
  • Отличное решение для конечных пользователей с точки зрения удобства программирования.

Минусы:

  • Проблемы с производительностью, т.к. интерпретированный язык медленнее скомпилированного.
Ссылка на основную публикацию
Adblock
detector