4.Архитектурные стили: компонентный, многослойный, многоуровневый, клиент-сервер.

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

Архитектура касается внешней части интерфейсов, внутренние детали элементов не являются архитектурными.

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

В данный момент различают:

Клиент/серверная архитектура

Серверное приложение, к которому напрямую обращаются множество клиентов. Имеет тенденцию тесного связывания данных и бизнес-логики приложения на сервере. Для решения этих проблем архитектурный стиль клиент/сервер был развит в более универсальный 3-уровневый (или N-уровневый).

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

Недостатки: низкая масштабируемость.

Компонентная архитектура

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

Многослойная архитектура

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

N-уровневый / 3-уровневый

Разделение функциональности на сегменты, во многом аналогично многослойной архитектуре, но выделенные сегменты могут физически размещаться на разных компьютерах

5.Компонентный архитектурный стиль. Принцип слабой связанности. Контейнеры зависимостей

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

Основной принцип компонентного стиля – применение компонентов, обладающих следующими качествами:

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

2. Замещаемость. Компоненты могут без труда заменяться другими подобными компонентами.

3. Независимость от контекста. Компоненты проектируются для работы в разных средах и контекстах.

4. Расширяемость. Компонент может расширять существующие компоненты для обеспечения нового поведения.

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

6. Независимость. Компоненты проектируются с минимальными зависимостями от других компонентов. Таким образом, компоненты могут быть развернуты в любой подходящей среде без влияния на другие компоненты или системы.

Для управления зависимостями между компонентами, поддержки слабого связывания и повторного использования могут использоваться шаблоны проектирования, такие как Dependency Injection (Внедрение зависимостей) или Service Locator (Локатор сервиса). Такие шаблоны часто применяются при создании составных приложений, сочетающих и повторно использующих компоненты во многих приложениях.

Dependency Injection (Внедрение зависимостей)

Внедрение зависимости (англ. Dependency injection) обозначает процесс предоставления внешней зависимости программному компоненту.

Используя внедрение зависимости, объект просто предоставляет свойство, которое в состоянии хранить ссылку на нужный тип сервиса; и когда объект создается, ссылка на реализацию нужного типа сервиса автоматически вставляется в это свойство (поле), используя средства среды. Внедрение зависимости более гибко, потому что становится легче создавать альтернативные реализации данного типа сервиса, а потом указывать, какая именно реализация должна быть использована в, например, конфигурационном файле, без изменений в объектах, которые этот сервис используют. Это особенно полезно в юнит-тестировании, потому что вставить реализацию «заглушки» сервиса в тестируемый объект очень просто. С другой стороны, излишнее использование внедрения зависимостей может сделать приложения более сложными и трудными в сопровождении: так как для понимания поведения программы программисту необходимо смотреть не только в исходный код, а еще и в конфигурацию, а конфигурация, как правило, невидима для IDE, которые поддерживают анализ ссылок и рефакторинг, если явно не указана поддержка фреймворков с внедрениями зависимостей.