Оптимизация приложений для работы с СУБД InterBase - Клиент-сервер против многозвенной архитектуры
ОГЛАВЛЕНИЕ
Клиент-сервер против многозвенной архитектуры
Традиционно под термином "клиент-сервер" принято понимать приложение, которое обращается напрямую к серверу баз данных и содержит в себе бизнес-логику процессов работы. А "многозвенная архитектура" также в традиционном понимании подразумевает наличие тонкого клиента, который обращается к серверу приложений, а он, в свою очередь, обращается уже непосредственно к серверу баз данных. Бизнес-правила при этом расположены на промежуточном слое — то есть на сервере приложений.
Замечу, что "псевдомногозвенная" архитектура, когда исполняемый файл содержит слои как сервера приложений, так и тонкого клиента, сейчас очень популярна. В такой модели существует четкое разделение в коде на сервер приложений (бизнес-правила) и тонкого клиента (представление данных). Но рассмотрение преимуществ той или иной модели проектирования выходит за рамки этой статьи. Поэтому, когда говорится о "многозвенных приложениях", имеются в виду как действительно многозвенные, с выделенным сервером приложений, программные комплексы, так и "псевдомногозвенные", в которых два слоя объединяются в одном исполняемом файле. С точки зрения оптимизации они очень похожи.
Существует, кроме всего вышеописанного, несколько различий между архитектурой клиент-сервер и многозвенной архитектурой с точки зрения оптимизации. Я не буду описывать оптимизацию работы DCOM-приложений, но одно из очень важных отличий проистекает из того, что сервер приложений должен быть "бессостоятельным" (от англ. stateless).
В приложении, основанном на архитектуре "клиент-сервер", считается вполне допустимым открытие запроса и поддержание его в таком состоянии довольно долго. СУБД семейства InterBase/Firebird имеют некоторые определенные проблемы в работе при наличии транзакции, активной достаточно длительное время, которые будут обсуждаться чуть ниже. Но наличие запроса, открытого в течение нескольких минут, не вызовет, скорее всего, никаких проблем в приложении клиент-сервер. Многозвенные же приложения, со своей стороны, требуют возврата результатов запроса, посланного тонким клиентом серверу приложений, в вызове одного и того же метода.
Стандартный компонент TClientDataSet ведет себя так, как описано выше при установке свойства PacketRecords в значение -1, а это свойство принимает такое значение по умолчанию. В многозвенных приложениях существует возможность "листать" большой набор данных, получая каждый раз по несколько новых строк данных. Но каждая такая "страница" должна быть возвращена в ответ на отдельное обращение к серверу приложений. Во многом такие страницы данных напоминают результат поиска поисковой машины Google, где каждая страница представляет собой отдельный запрос к поисковому серверу. Так как сервер приложений не сохраняет состояния выполненных запросов, мы не можем предполагать, что в ответ на запрос о получении следующей "страницы" данных получим ту "страницу", которую ожидаем увидеть.
На практике это означает, что в приложении на основе архитектуры клиент-сервер вы можете избежать трудностей, которые нельзя обойти в многозвенном приложении. В приложении клиент-сервер, к примеру, вы можете вызвать запрос, возвращающий около 1000 записей, а затем подгружать остальные записи по мере навигации по набору данных, и это не вызовет снижения скорости работы приложения. В некоторых случаях даже при результате в миллионы записей при условии, что вы не пытаетесь получить с сервера их все сразу, замедление работы программы не будет наблюдаться вообще или будет ничтожно мало. В многозвенных приложениях проектировщик должен гарантировать, что клиент вызовом запроса, возвращающего даже всего несколько тысяч записей, не вызовет перегрузку всей системы, что выльется в недопустимо большие задержки в работе пользовательского интерфейса, проще говоря, в ее "задумчивость". Это означает, что многозвенные системы должны изначально разрабатываться так, чтобы они никогда не запрашивали большие объемы данных. Конечно, в системах клиент-сервер таких жестких ограничений не существует, но в многозвенных системах это правило должно строго соблюдаться и постоянно учитываться с самого начала проектирования приложения.
Технологии dbExpress и ADO.NET для интерактивных приложений практически требуют использования многозвенной архитектуры, и, по мнению многих, многозвенная архитектура должна использоваться во всех приложениях, за исключением самых простейших. В то время как подобное построение приложения налагает определенные ограничения на его дизайн, которые могут сначала показаться обременительными, это позволяет лучше масштабировать систему, чем при использовании классического подхода клиент-сервер.