2012-04-24 1 views
1

Я пытаюсь выяснить, как сделать реализацию базы данных Android для Cursor, чтобы обернуть слой базы данных ORMed.ICursor реализация для ORM в MonoDroid

Чтобы ОРМ в MonoDroid мы можем использовать sqlite-net проект (очень легкий ORM) или ServiceStack.OrmLite

Мои мысли реализовать ICursor интерфейс и «завернуть» ОРМ Сейчас я просто не могу установить его в моем уме как он должен работать, и должен ли он работать когда-либо или нет. Должен ли он загружать набор кадров в рамку или получать его один за другим? Что лучше для производительности, как получить значения столбцов - отражение или ..?

Итак, на самом деле вопрос: возможно ли это когда-либо? Любые мысли будут оценены.

Спасибо.

ответ

1

Я не уверен, что «проблема», которую вы пытаетесь решить с помощью реализации ICursor, возможно, вы должны быть немного более конкретными относительно конкретной задачи, которую вы пытаетесь сделать. Вся точка ORM (и вы пропустили this one that also supports SQLite on Android) - это абстрагировать всю парадигму RDBMS от кода и вместо этого дать вам объектно-ориентированную парадигму.

ICursor возвращает вам обновляемый набор результатов из SQL-запроса, что означает, что вам нужно знать о строках, наборах результатов, запросах и т. Д. ORM возвращает объект или коллекцию объектов. Если вы хотите его обновить, вы обновляете объект и отправляете его обратно в ORM.

Теперь я полностью признаю, что бывают случаи, когда ORM не могут обеспечить самый чистый механизм для выполнения чего-либо, что может сделать SQL-запрос. Например, если вы логически хотели «удалить все детали, созданные вчера во время второй смены». Легкий ORM может предоставить вам все части, а затем вы должны использовать LINQ или аналогичный фильтр, который в нужный день и смену, а затем итерацию, что результирующая коллекция, чтобы удалить каждый, тогда как с SQL-запросом вы просто передаете DELETE FROM Parts WHERE BornONDate BETWEEN @start AND @end, но это один из компромиссов, с которыми вы сталкиваетесь.

В некоторых случаях ОРМ может предоставить возможность делать то, что вы хотите. Например, в ORM OpenNETCF, приведенном выше, вы можете отбросить свой DataStore (если он еще не) в SQLDataStore, а затем у вас есть доступ к методу ExecuteNonQuery, позволяющий вам передать непосредственный оператор SQL. Если у вас все еще нет средств для передачи вам набора записей, потому что, как я уже сказал, возвращающиеся строки базы данных действительно являются антитезой или ORM.

Существует также некоторый собственный риск при использовании чего-то вроде ExecuteNonQuery. Если вы хотите изменить свой резервный магазин, скажем, RDBMS, например SQLite, на нечто совершенно иное, как база данных объектов, XML-файл или что-то еще, тогда ваш код, который строит и использует запрос SQL, прерывается. По общему признанию, это может быть не распространено, но если переносимость кода и расширяемость и на вашем радаре, то это, по крайней мере, что-то нужно иметь в виду.

+0

Благодарим вас за ответ. На самом деле я знаю все преимущества/недостатки ORM. Поэтому я предпочитаю использовать уровень базы данных, основанный на ORM, в Android-приложениях, но Android предполагает использовать [ContentProvider class] (http://docs.mono-android.net/?link=T%3aAndroid.Content.ContentProvider), который заключает сделку с курсором. Поэтому я решил реализовать «совместимость» между ORM и ContentProviders. Конечно, самый простой способ - не использовать Провайдеров, а может быть, это только путь с ORM? – Anton

+0

И спасибо за ссылку на OpenNETCF.ORM Framework, я действительно пропустил ее, когда искал доступные ORM – Anton