Развертывание и управление версиями приложений

В данном разделе описывается развертывание клиентских и серверных приложений, а также управление их версиями. Сведения об инициализации одноранговых БД см. в разделе «Инициализация базы данных сервера» документа Как настроить и выполнить синхронизацию совместной работы (не SQL Server).

Развертывание двухуровневых и многоуровневых клиентских и серверных приложений, использующих платформ Sync Framework, производится по-разному. В двухуровневом приложении весь код синхронизации размещается на клиенте, поэтому его развертывание может быть произведено точно так же, как и любое другое приложение на основе SQL Server Compact. Обычно развертывание производится его публикацией с помощью ClickOnce или упаковыванием с последующим копированием на каждый из клиентских компьютеров. Дополнительные сведения о развертывании приложений, использующих SQL Server Compact, см. в разделах «Развертывание приложений» и «Как создавать и развертывать приложения для настольных компьютеров» в электронной документации по SQL Server Compact. Для многоуровневых приложений необходимо также развертывание кода на компьютере, на котором располагаются серверные компоненты синхронизации.

Создание и инициализация клиентской базы данных

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

При помощи служб Sync Framework создать базу данных и загрузить схему и данные таблицы во время первой синхронизации. Это наиболее простой способ, однако при большом числе клиентов и объеме данных он может вызвать интенсивность сетевого трафика и нагрузку на сервер.

Заранее подготовить базу данных со схемой таблиц и начальным набором данных. Базу данных в формате SDF-файла можно перенести и загрузить с помощью клиентского приложения. При загрузке добавочных изменений приложение при проведении первой синхронизации обновит клиентскую базу данных. При использовании этого подхода присвойте соответствующее значение свойству CreationOption.

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

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

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

Дополнительные сведения об инициализации клиентской базы данных см. в разделе Как инициализировать клиентскую базу данных и работать со схемой таблицы.

Управление версиями приложений

После создания и развертывания приложения обычно появляются его новые версии. В процессе управления версиями необходимо учитывать два обстоятельства:

компоненты приложения, которые изменились в новой версии;
должна ли новая версия работать параллельно с предыдущими версиями.

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

Управление версиями многоуровневых приложений

Главное обновление, которое должно быть выполнено для приложения, использующего службы Sync Framework, — изменение схемы базы данных на сервере. Службы Sync Framework не передают изменения схемы сервера клиенту автоматически. Однако изменения схемы поддерживаются после обновления соответствующих компонентов приложения. Список изменений схемы, поддерживаемых в клиентской базе данных, см. в разделе Работа со схемами таблиц. Если изменение схемы произведено в базе данных сервера, то сначала необходимо решить, должно ли оно вообще передаваться клиенту. Например, если в базе данных на сервере добавлен столбец с номерами кредитных карт, но бизнес-правила запрещают сотрудникам перемещать сведения о кредитных картах в автономные хранилища, то передавать это изменение схемы клиенту не нужно. Если принято решение о распространении изменения схемы, то его способ зависит от типа изменения.

Типичные изменения схемы

Два наиболее типичных изменения схемы — это добавление столбца к существующей таблице и добавление новой таблицы, а также включение существующей таблицы, которая изначально не являлась частью приложения. Если приложению необходимо синхронизировать новую таблицу, то для нее необходимо добавить SyncAdapter. После обновления серверных компонентов клиентское приложение или пользователь приложения решает, следует ли синхронизировать новую таблицу. Если принято положительное решение, то клиентские компоненты необходимо изменить, включив для новой таблицы SyncTable. Эти изменения должны быть каким-либо способом переданы в каждое клиентское приложение. Технология ClickOnce позволяет опубликовать обновление приложения, а приложение может перед запуском проверить его наличие. Если в таблицу добавляется новый столбец, который необходимо синхронизировать, то следует добавить этот столбец в клиентскую базу данных и изменить команды, применяемые для синхронизации изменений. Для других изменений схемы (помимо добавления нового столбца) таблицу на клиенте необходимо удалить и создать повторно с помощью служб Sync Framework или какого-либо другого механизма.

Параллельно работающие версии

В некоторых случаях новые и старые версии клиентского приложения должны работать параллельно. Для таких случаев существует два различных подхода.

Поддерживать несколько версий компонентов на сервере, чтобы старые версии клиентских компонентов могли обращаться к соответствующим версиям серверных компонентов. Лучший метод управления версиями — предоставление доступа к новой службе с обновленной функциональностью. Клиенты можно обновить с помощью технологии ClickOnce. По завершении обновления клиент будет перенаправлен к новой веб-службе.

Разработать клиентские и серверные компоненты, использующие параметр версии приложения. Такой подход позволяет клиентскому приложению известить сервер об ожидаемой им версии. В следующем примере хранимая процедура, производящая выборку с сервера операций вставки, принимает параметр @appversion. Этот параметр добавляется в команду SelectIncrementalInsertsCommand, а затем через SyncParameter передается в SyncAgent. При выполнении синхронизации версия приложения пересылается на сервер и хранимая процедура выбирает нужную версию схемы таблицы.

this.Configuration.SyncParameters.Add(
      new SyncParameter("@appversion", 1));
customerIncrUpdates.Parameters.Add("@appversion", SqlDbType.Int);

Me.Configuration.SyncParameters.Add( _
      New SyncParameter("@appversion", 1))
customerIncrUpdates.Parameters.Add("@appversion", SqlDbType.Int); 

CREATE PROCEDURE usp_CustomerSelectIncrementalInserts(
    @sync_last_received_anchor timestamp, 
    @sync_new_received_anchor timestamp, 
    @appversion int
)

AS
    IF @appversion = 1
    BEGIN
        SELECT CustomerId, CustomerName, SalesPerson
        FROM Sales.Customer 
        WHERE InsertTimestamp > @sync_last_received_anchor 
        AND InsertTimestamp <= @sync_new_received_anchor
    END
    ELSE IF @appversion = 2
    BEGIN
        SELECT CustomerId, CustomerName, SalesPerson, CustomerType
        FROM Sales.Customer 
        WHERE InsertTimestamp > @sync_last_received_anchor 
        AND InsertTimestamp <= @sync_new_received_anchor
    END
    ELSE
    BEGIN
        PRINT('Unrecognized version')
        RETURN
    END

См. также

Основные положения

Архитектура и классы для синхронизации клиента и сервера
Рекомендации по разработке и развертыванию приложений

Last updated on 2009-10-17