2-х уровневая -- это клиент-серверная, где вся функциональность разнесена на две составляющих:
база(ы) данных
клиенты этой(их) баз данных
причём каждый из них занимается "своим делом":
база данных, с классическим набором в ней средств, обеспечивает: хранение, доступ, контроль целостности, контроль корректности значений, транзакционность групповых изменений, резервное копирование, и т.д. и т.п.
средствами клиентов, обеспечивается работа с проекциями данных из БД на их задачи.
Проблемы:
Если несколько однотипных клиентов (а такое всегда есть :-), то что делать? Хотелось бы логику их типичной работы с данными как-то "централизовать" (т.е. "нормализовать" код :-). Возможны два решения:
выделять это всё в хранимые процедуры сервера (однако, хочу заметить, что писать обработку данных на T-SQL не для слабых :-) в случае если БД будет SQL Srver, конечно). К тому же, если эта логика подвержена частым изменениям, придётся и часто "тревожить" базу данных, внося изменения, которые к данным, как таковым, отношения не имеют.
прописывать в код на клиенте (однако это уже "денормализация" :-( и этого следует всячески избегать :-). Как достаточно элегантное решение на этом пути, казалось бы, VFP позволяет использовать Фоксову базу данных для этих целей, обеспечивая "однозадачных" пользователей как необходимыми им данными, так и логикой работы с ними... Однако, это опять приводит к определённому множеству, хоть и более мелких проблем :-) В частности:
дублирования всё равно не избежать, поскольку разным группам пользователей всё равно потребуется нечто общее как по данным, так и по их обработки.
трудно надёжно обеспечить транзакционность групповых изменений
и т.п.
По этому первый случай, всё-таки как-бы более разумный, однако, при этом "очень толстым" (многофункционально специализированным) становится сам сервер БД, к тому же подверженный частым изменениям... короче, со всеми вытекающими отсюда последствиями.
3-х уровневая использует еще посредником и COM объекты
По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:
масштабируемость
конфигурируемость — изолированность уровней друг от друга позволяет (при правильном развертывании архитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней
высокая безопасность
высокая надёжность
низкие требования к скорости канала (сети) между терминалами и сервером приложений
низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Терминалом может выступать не только компьютер, но и, например, мобильный телефон.
Недостатки
Недостатки вытекают из достоинств. По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:
более высокая сложность создания приложений;
сложнее в разворачивании и администрировании;
высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;
высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.
Пример трёхзвенной архитектуры клиент-сервер
Компоненты трёхзвенной архитектуры, с точки зрения программного обеспечения реализуют определенные сервера БД, web-сервера и браузеры. Место любого из этих компонентов может занять программное обеспечение любого производителя. Ниже представлено описание взаимодействия компонентов трехуровневой архитектуры клиент-серверного приложения. Сервер БД представлен MySQL-сервером; сервер приложений технологиями: ADO.NET, ASP.NET и web-сервером IIS; роль клиента выполняет любой web-браузер.
Браузер клиента 1-> Сервер IIS 2-> Исполняющая среда ASP.NET 2.0 3-> Провайдер данных ADO.NET 2.0 4-> Сервер MySQL 5-> Провайдер данных ADO.NET 2.0 6-> Исполняющая среда ASP.NET 2.0 7-> Сервер IIS 8-> Браузер клиента
