Главная Случайная страница


Полезное:

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


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






Разновидности Web-приложений





Распределенная архитектура, как наиболее подходящая для Business Web Application (BWA).

 

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

Виды распределенной архитектуры:

1. 2-x уровневая архитектура (Клиент-Сервер)

 

 

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

2. 3-x уровневая архитектура (идеальный вариант)

 

3-х уровневая архитектура подразумевает четкое выделение бизнес-логики. Сервисы для вызова бизнес-логики (2nd tier), относятся к 1st tier. А интерфейс с базой данных (или любым источником данных) - сразу к 3rd tier. Данныей подход позволяет четко очертить границы уровня бизнес-логики и отличие 3-х уровневого подхода от 2-х уровневого (клиент-сервер).

3. 3-x уровневая архитектура (фактический вариант)

На практике по различным причинам бизнес-логика остается на 1st и 3rd tier. Это может быть оправдано, если не приведет к перегрузке уровня, на котором находится ненормированный код. И если этот код легко можно перенести в 2nd tier объекты. Например, поместив бизнес-логику в хранимые процедуры в 3rd tier, можно получить большой выигрыш в производительности. Если же эти хранимые процедуры написаны на Java, то перенести их в 2nd tier будет несложно. А вот бизнес-логика на 1st tier распространена повсеместно, и, обычно, связана с неудачной архитектурой.

Основные критерии идеальной распределенной архитектуры:

1. Каждый уровень распределенного приложения может взаимодействовать только со смежным уровнем. Это означает, что: 1st tier не должен иметь прямого доступа к 3rd tier и наоборот; 2nd и 3rd tiers не должны иметь прямого интерфейса с пользователем; обращение к источнику данных из 1st tier происходит только через объекты 2-nd tier;

2. Вся сложная бизнес-логика находится в объектах 2nd tier. Как уже упоминалось, это условие часто нарушается, снижая возможность масштабирования. Хотя подобные решения иногда оправданы.

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

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







Date: 2015-07-27; view: 963; Нарушение авторских прав



mydocx.ru - 2015-2024 year. (0.005 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию