2013-03-08 1 views
0

Я немного путаюсь из-за моего меньшего понимания о CouchDB. Позвольте мне объяснить простыми словами. Я разрабатываю приложение iphone, для которого мой клиент может запросить версию для Android. Я использую CouchDB для хранения данных для этого приложения.Является ли CocuchDB/TouchDB предназначенным для автономной/онлайн-настройки для приложений ios?

Мы разработали бэкэнд, откуда администратор может установить/обновить информацию. Вся обновленная информация должна быть реплицирована на все устройства iphone. Когда я говорю репликацию с сервера на устройство, я не имею в виду репликацию с одного устройства iphone на другое. Средством источника обновления всегда будет сервер.

Мой клиент также хочет, чтобы большая часть функциональности, если возможно, работала в автономном режиме. Чтобы сделать некоторые из автономных клиентов функциональности, попросил меня использовать CouchDB и TouchDB (на iphone), которые будут синхронизироваться автоматически.

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

Использование CouchDB/TouchDB У меня много проблем. Одна из серьезных проблем заключается в том, что моя логика и реализация пользовательского интерфейса вместе построены на моем xcode. Если завтра я захочу разработать Android-приложение, то снова я должен реализовать ту же логику в синтаксисе android. Изменение логики требует обновления обеих версий. Больше разочаровывает, если клиент хочет разработать окна и версию BB завтра.

Чтобы избежать этого, я могу предложить моему клиенту, что мы должны использовать трехуровневую архитектуру, где мы построим одно среднее изделие, и мы сохраним свою логику там. Только работа, которую мы должны развивать на уровне приложения, - это получение данных из промежуточного продукта через WebService и существующий пользовательский интерфейс.

Но прежде чем предлагать моему клиенту, я хочу подтвердить свою идею из опыта. Возможно, я ошибаюсь, поскольку я не очень хорошо разбираюсь в CouchDB, и, возможно, CouchDb предназначен только для автономной/онлайн-настройки.

Пожалуйста, подождите, пожалуйста, от эксперта.

+0

Я бы предложил сделать то, что соответствует вашим навыкам и требованиям вашего клиента. Вы можете переместить логику синхронизации на третий уровень, но трудно сказать, облегчает ли это логику клиента.Похоже, вы просто двигаете проблему и увеличиваете количество точек отказа. – WiredPrairie

+0

«Похоже, вы просто перемещаете проблему и увеличиваете количество точек отказа». как? – SangamAngre

+0

Сохранение логики в одном месте, которое будет применимо для всех (iphone/android/windows/BB), не очень хорошая идея. 3 уровня - общепринятый подход. Не так ли? – SangamAngre

ответ

3

Я сейчас работаю над чем-то похожим, поэтому могу поделиться тем, что нашел.

Мы используем BigCouch (вилку CouchDB, управляемую Cloudant, которая предоставляет кластер машин Couch) для хранения наших данных, а затем с помощью TouchDB для iOS для репликации данных до мобильных устройств.

Мы смогли получить TouchDB, работающий с BigCouch, но он не был без нескольких ударов по дороге. TouchDB использует существующие функции репликации, встроенные в CouchDB, и хорошо справляется с этим.

Из моего опыта TouchDB также отлично работает в автономном режиме. Репликация закроется, когда она перестанет работать, когда устройство отключилось. Вы также можете настроить Touch, чтобы делать нажатия, тянуть - или и то, и другое, так что это хорошо.

Настоящая проблема заключается в том, когда вы хотите перейти на Android. В настоящее время порт TouchDB Java находится в очень жарком состоянии. Он существует, но он не готов к производству. Фактически я видел в Твиттере только на этой неделе, что они пытаются нанять кого-то, чтобы взять на себя проект.

Даже если Java-порт TouchDB был готов к производству, вы правы, вам придется переписать код для Android. Тогда это будет так, независимо от того, какую технологию вы используете.

+0

SO использование трехуровневой архитектуры здесь не полезно? Это также снизит мою стоимость обслуживания, а изменение логики приведет к изменению на среднем уровне, а не на уровне приложений, верно? – SangamAngre

Смежные вопросы