В этой схеме собраны почти все варианты названий трех уровней распределенного приложения. Чтобы избежать путаницы, будем именовать уровни так: 1st tier, 2nd tier и 3rd tier, по причине краткости написания. Выбирать названия по другим критериям слишком сложно. Называть 3-х уровневую архитектуру N-уровневой вероятно не стоит, т.к. эти N уровней, обычно, появляются как более детальное изображение той же 3-х уровневой схемы, не внося принципиально новых идей. N-уровневые схемы удобны чтобы показать систему с точки зрения развертывания и администрирования. Но с точки зрения разработки эти дополнительные уровни малоинтересны.
Три уровня (с позиции программирования) - это хранение, обработка и представление информации. Идея заключается в том, чтобы не смешивать эти три составляющие. Грубо говоря, 3-х уровневый подход - это просто хороший стиль программирования. Его можно применять при разработки практически любых приложений. Новизна же и идея распределенных приложений в том, чтобы иметь возможность распределить эти три уровня физически на различных компьютерах, а также возможность иметь несколько взаимозаменяемых вариантов каждого уровня.
2-x уровневая архитектура (Клиент-Сервер)
В классической архитектуре клиент-сервер, бизнес-логика может располагаться как у клиента, так и на сервере. В результате существует тенденция смешивания бизнес-логики с интерфейсом пользователя и/или со структурой БД.
3-x уровневая архитектура (идеальный вариант)
3-х уровненая архитектура подразумевает четкое выделение бизнес-логики.
Интересно отметить, что сервисы для вызова бизнес-логики (2nd tier), относятся к 1st tier. А вот интерфейс с базой данных (или любым источником данных) - сразу к 3rd tier. Такой подход позволяет четко очертить границы уровня бизнес-логики и отличие 3-х уровневого подхода от 2-х уровневого (клиент-сервер).
3-x уровневая архитектура (фактический вариант)
На практике, мы имеем нечто подобное. По различным причинам бизнес-логика остается на 1st и 3rd tier. Это может быть оправдано, если не приведет к перегрузке уровня, на котором находится ненормированный код. И если этот код легко можно перенести в 2nd tier объекты. Например, поместив бизнес-логику в хранимые процедуры в 3rd tier, мы можем получить большой выигрыш в производительности. Если же эти хранимые процедуры написаны на Java, то перенести их в 2nd tier будет несложно. А вот бизнес-логика на 1st tier распространена повсеместно(как уже упоминалось), и, обычно, связана с неудачной архитектурой. Вопрос о бизнес-логике в ASP-страницах мы рассмотрим позднее.
Теперь, попытаемся выявить основные критерии идеальной распределенной архитектуры:
-
Каждый уровень распределенного приложения может взаимодействовать только со смежным уровнем.
Это означает, что: 1st tier не должен иметь прямого доступа к 3rd tier и наоборот; 2nd и 3rd tiers не должны иметь прямого интерфейса с пользователем; обращение к источнику данных из 1st tier происходит только через объекты 2-nd tier; -
Вся сложная бизнес-логика находится в объектах 2nd tier.
Как уже упоминалось, это условие часто нарушается, снижая возможность масштабирования. Хотя подобные решения иногда оправданы. -
Взаимодействие уровней организовано так, чтобы они могли взаимодействовать по сети, находясь физически на различных компьютерах.
Это означает, что распределенная архитектура не зависит от способа развертывания (deployment) приложения - все уровни могут быть размещены физически как одном компьютере, так и на разных, в условиях заданной сетевой структуры; -
Сущности данных независимы от способа их хранения, уникально идентифицируемы по какому-либо ключу, и независимы от способа и места хранения других сущностей.
Это, в частности, иногда означает отсутствие в некоторых таблицах связей по внешним ключам, что позволяет хранить группы таблиц, имеющих отношение к одной сущности, в разных базах данных. Однако тогда необходимо отслеживать целостность данных дополнительным кодом.
Проблема ASP заключается в том, что смесь скрипта бизнес-логики, HTML и SQL представляет собой 2-х уровневую архитектуру (клиент-сервер), которая с задачами Web-приложений не справляется. Поэтому мы предложим способ как разделить ASP на три составляющие - ASP-код с бизнес-логикой, HTML и SQL.
Пожалуй, многие задумывались о создании web-сайта. Но вот пробиться в верхние строчки поиска достаточно сложно. В Интернете огромное количество сайтов, и, соответственно много конкурентов. Для вас нужно грамотное создание и продвижение сайтов. Грамотно пользуясь инструментами создания и продвижения сайтов, поисковой оптимизацией, ваш сайт станет лидером среди конкурентов.