Войти



Поиск

Реклама

Выбирать Горящий тур в Турцию: виза в оаэ без тура. Горящие туры ! Спешите.

Полезное:

Новые статьи

Опечатка?

Выделите текст и нажмите Shift+Enter.
И мы в ближайшее время ее исправим!

Счетчики


Уровни и ярусы

Следует различать уровни (layer) и ярусы (tier). Иногда термин «многоярусная (n-tier) архитектура» применяется некорректно.

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

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

Например, если запрос получает доступ к таблице Customers в 20 отдельных формах, а вы затем изменяете структуру таблицы Customers (скажем, удаляете или добавляете столбец), то внесенные изменения следует отследить во всех задействованных формах непосредственного доступа к базе данных и отредактировать запросы. А если весь доступ к базе данных сосредоточен на уровне доступа к данным и для непосредственного доступа к таблице Customers используется только один класс, то модифицировать придется только этот класс.

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

Такой подход позволяет использовать класс доступа к данным в разных точках разрабатываемого приложения без необходимости переписывать при этом код запросов, а это обеспечивает существенную экономию времени разработки. И наконец, не следует сбрасывать со счетов преимущества описываемой технологии в плане упрощения сопровождения готового приложения (да и сам программный код такого приложения проще и понятнее). В больших приложениях нередко встречается ситуация, когда разработку программного кода разных уровней ведут разные специалисты. Отделение всего кода доступа к данным от кода приложения Windows Forms позволяет поручать разработку последнего специалистам, несведущим в SQL (и не желающим его изучать).

Разработчики часто задают вопрос о том, к чему им выделять часть приложения в отдельный рабочий уровень, если решаемые задачи не содержат сколько-нибудь сложной рабочей логики? Зачем разрабатывать отдельный уровень (со всем его классами и прочими аксессуарами), который фактически будет только передавать данные с уровня доступа к данным и обратно? Не слишком ли велики затраты на проектирование (а позже и на сопровождение) кода, который практически ничего не делает?

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




Newer news items:
Older news items:

 
Главная Страница Контактная Информация Поиск по сайту Контактная Информация Поиск по сайту