Ваш подход правильный. Вам нужно будет создать абстракцию сервисов, с которыми приложение будет взаимодействовать, а затем предоставить 2 различные реализации: 1 для веб-приложения, которое может использовать удаленное взаимодействие через AMF, веб-службы или службы http, и 1 для настольного приложения, иметь реализацию SQLite.
Этот подход является в основном реализацией шаблона стратегии, который является базовым шаблоном в фреймворке Spring ActionScript . Включен Operation API , который поможет вам в создании интерфейсов для классов обслуживания, так как они будут иметь асинхронные подписи. Приятно то, что есть также поддержка создания реализаций заглушки, так что вы можете протестировать свое приложение, не полагаясь на реальную реализацию для веб-клиента или клиента рабочего стола. Платформа также предоставляет другой механизм конфигурации, так что вы можете развернуть свое приложение и предоставить стратегию, которую необходимо использовать во время выполнения.
Я говорил о Spring ActionScript, в котором я обсуждаю Operation API: http://parleys.com/#sl=25&st=5&id=1566
В коде ваш сервисный код может выглядеть примерно так:
// interface
public interface IUserService {
function getUserByID(id:String):IOperation;
}
// implementation A
public class UserServiceA implements IUserService {
public function getUserByID(id:String):IOperation {
// return implementation specific operation
}
}
// implementation B
public class UserServiceB implements IUserService {
public function getUserByID(id:String):IOperation {
// return implementation specific operation
}
}
Конечным результатом является то, что ваше приложение общается с IUserService и ничего не знает о реальных реализациях. Реализации могут быть сконфигурированы и управляться в контейнере Spring ActionScript и автоматически вводиться для вас.