Тот, кто дает вам прямой ответ на этот вопрос, не знает, о чем говорит.
Одна из самых больших проблем (читай: Почему на самом деле работают разработчики) заключается в том, что создать отключенного клиента сложно.
Не очень сложно, но это требует опыта разработки программного обеспечения и ранних компромиссов и планирования.
Вопрос, который вы задали, по сути, «Ну, как мне построить Smart Client?»
По этой теме было написано много замечательных книг и десятки фреймворков. Так что, как я уже говорил, здесь нет простого ответа.
Первое, что вы должны спросить себя: какой уровень Smart Client вам нужен?
Вы строите полностью отключенного клиента? Полу онлайн / оффлайн клиент? Частично включенный автономный клиент? и т. д. и т. д.
Я обычно смотрю на это через особенности:
- Сценарий, который вы пытаетесь поддержать временную потерю подключения к сети?
Или длительная потеря сетевого подключения?
Продолжительность времени автономной работы (в частности, при перезагрузке приложения) определяет, будет ли ваш кэш сохраняться на диске или может быть доверен оперативной памяти.
- Уверен ли клиент в запуске с сетевым подключением?
Или есть возможность запуска OOB без подключения к сети?
Если клиент может запускаться из OOB без подключения к сети, вам придется хранить автономные данные на диске. У вас не будет возможности получать свежие данные с сервера при запуске.
- Может ли пользователь запрашивать ранее полученные данные в автономном режиме?
Это один общий поток между всеми умными клиентами.
Все приложения Smart Client имеют доступ к автономным данным, но важно назвать это функцией IMO.
- Может ли пользователь создавать новые данные в автономном режиме?
Итак, если у вас есть приложение Закупки, и нет сетевого подключения, может ли пользователь создать новый Заказ?
Если это так, вам придется кэшировать эти данные локально и передавать их на сервер в первом цикле Client <-> Sync.
- Каков объем данных, которые можно изменить в автономном режиме?
Можете ли вы ограничить автономную функцию только созданием важных данных?
Или вам нужно разрешить весь спектр создания и обновления и удаления для всех ваших данных в автономном режиме?
Я предлагаю ограничить автономные изменения, так как вы столкнетесь с очень сложными сценариями, которые нужно решить, если вы этого не сделаете.
Например, в 12:00 пользователь А удаляет клиента № 1, а в 12:05 пользователь Б выпускает новый заказ для клиента № 1. Оба пользователя были в автономном режиме. А теперь поймите, какое там правильное бизнес-решение:)
Редактировать: фиксированный пример;)
- Что происходит в автономном режиме, когда пользователь запрашивает данные, которые ранее не были получены?
Давайте предположим, что ваши общие данные (например, таблица клиентов) огромны.
У вас есть 10 миллионов клиентов. Вы не можете хранить эти конфиденциальные данные на всех клиентах.
Так что же происходит, когда автономное приложение нуждается в избытке для клиента, которого у него нет?
Вы согласны с тем, чтобы сказать конечному пользователю: «Войдите в чертову сеть, не так ли?».
- Насколько критически важна ваша программа?
Интересная часть в этом вопросе - если что-то пойдет не так, ты в порядке с отключением этого пользователя?
Этот вопрос определяет, нужно ли вам сохранять данные на диске при каждом действии данных (новые данные, извлеченные данные, поле изменения формы и т. Д.) Или все в порядке с сохранением на диске только после закрытия приложения.
Когда вы смотрите на Silverlight, у вас есть несколько хороших технических опций.
Хранить данные в памяти.
Если ваш набор функций сохранился, сохраните контекст домена служб RIA как статический экземпляр.
когда клиент теряет подключение к сети, вы все равно получаете работать от оперативной памяти.
Как упоминалось ранее, IsoStore - ваш друг.
Вы получаете 1 МБ (в браузере) / 25 МБ (вне браузера) вашего собственного магически частного дискового пространства, и если вашему приложению это нужно - вы можете запросить больше.
Сериализация данных на диск.
OODB - Объектно-ориентированная база данных.
OODB, работающие в Silverlight IsoStore, являются удивительно простым способом сохранения данных.
Просто перейдите к Conext домена RIA Services и перейдите к «myEntity.Save ()».
В Silverlight IsoStore работают 3 OODB, о которых я знаю: db40, mcObjects и SilverlightDB.
Основываясь на сообщении в блоге NikhilK, которое было опубликовано несколько месяцев назад, RIA Services планирует поддерживать "отказоустойчивость". Но объем и сроки не указаны.
Приветствия
- Джастин