I am trying to convert a C# application we had developed to an iPad application. As we developed the app with Entity framework, I am looking for a counterpart for iOS.
According to this answer, there are several ORM libraries for SQLite in iOS:
But after reading each of the web sites, I still can't decide which package to use. Can anybody who has experience with one of them tell me advantages/disadvantages of the packages?
UPDATE: DBAccess has now been replaced by the open source ORM Shark.
We have recently released a free to distribute and use ORM for Objective-c / iOS called DBAccess, which can be downloaded from http://db-access.org/, it has taken several years to develop and has now been deployed within many applications.
It may not be for everyone, but I hope our effort will help some in the community.
NOTE, I have been alerted to the fact that it is bad form to promote your own products in a forum such as this, but I just wanted to add that I am only posting this in answer to the OP because I feel it does bring something useful to the table and I sincerely hope it will prove helpful to some people, even if it's not for everyone.
UPDATE: DBAccess has now been replaced by the open source ORM Shark. It is API compatible, and is available on github. http://sharkorm.com and https://github.com/sharksync/sharkorm
Thanks Adrian_H
I've dealt with the limited number of ORMs for quite some time, and I finally did something to improve the limited options available. I've written an ORM and released it under a BSD license for everyone to use. It's posted on GitHub.
The best way to convert an c# app to iOS is Xamarin i think, there is a library sqlite-net , works good.
TL;DR: LabQLite:
LabQLiteRowFull Disclosure: This is a library that I've developed. It is released into the public domain.
Long Version
Check out LabQLite. It's a little bit o' coin (depending on the license you get), but I think it is the strongest contender out there for SQLite on iOS.
It ships with a shell script that can analyze your SQLite database file for you, spit out class files corresponding to the tables and views. I noticed you mentioned that you are coming from a previous project. If you can export an SQLite db file from that project, you can be up-and-running with usable model classes in seconds (depending on db size) using the labqlitemodelgen.sh to get all your models.
Note: If your tables and views are named with underscores (e.g. my_table_name), the corresponding class that is generated will follow Objective-C naming conventions (e.g. MyTableName) - likewise for table columns to model class properties.
LabQLite in version 1.0 ships with 100 unit tests.
LabQLite also eliminates what I like to call the middle-level boilerplate. In other words, usually once you get all the C language low-level boilerplate written for a SQLite project on iOS, you still have to write CRUD methods for your models, and maybe you have to write helper methods (depending on your application) too. (EDIT: This is common with smaller open-source solutions).
With LabQLite, you don't write the middle- nor low-level bp. The generated model classes inherit from a superclass that does ALL that for you. Plus, the generated classes are not themselves filled with the CRUD methods - so your model class files end up looking cleaner than if they were filled with CRUD ;)
Integration is quick if you have the SQLite db file in your app's bundle:
/**
@abstract Activates a global singleton shared instance of an
LabQLiteDatabaseController with the database at the file path
specified.
@param filePath The file path to the sqlite3 database file in
the local bundle.
@param savePath The path (including file name) to which the
sqlite3 database file retrieved from the main bundle should
be saved.
@param NSDocumentDirectoryIsRootPath Prepends the savePath with
the path to the NSDocumentDirectory.
@param overwrite If set to YES, then this method will overwrite
any file it finds at the savePath. Otherwise, it will not.
@param error The standard error capturing double indirection
pointer.
@return Whether the activation of the shared database controller
was indeed successful.
@see
initWithFileInFromLocalBundle:toBeCopiedToAndUsedFromDirectory:assumingNSDocumentDirectoryAsRootPath:overwrite:error:
*/
+ (BOOL)activateSharedControllerWithFileFromLocalBundle:(NSString *)filePath
toBeCopiedToAndUsedFromDirectory:(NSString *)savePath
assumingNSDocumentDirectoryAsRootPath:(BOOL)NSDocumentDirectoryIsRootPath
overwrite:(BOOL)overwrite
error:(NSError **)error;
There are other fast integration approaches too if you don't put your SQLite db file in your app's bundle.
The code is adequately commented with both doc and inline comments throughout.
Another factor to consider is maintainability. Sure, the freebies have quick 'discoverability,' but what one quickly learns is that (a.) integration of the framework/library is fast, but (b.) maturating your app is slower because significant changes in your app require significant changes to your model code (i.e. mid and low boilerplate).
LabQLite is written in Objective-C and so is usable, say, in legacy systems as well as in modern apps.
LabQLite conceptually is like an 'extendable ladder.' That is, if you wanted, you could:
NSString queries into the database object or database controller object for processingSo, you are not pigeonholed into using LabQLite as an ORM... neither totally nor partially. There are even object types called LabQLiteStipulations which encapsulate logic for conditionals. So there's flexibility there, too.
Keep an eye on https://twitter.com/labitorysupport/ for updates.
Summary
The strengths of LabQLite are: