My class derived from SQLiteOpenHelper is getting huge

Question

My class derived from SQLiteOpenHelper is getting bigger and bigger over a time. At the speaking time it is more than 1500 lines of code which is not considered to

Answer 1

You should avoid putting all model specific code in your helper as you can. Think about it as something you could be able to reuse as much as you can in the next project. You can follow some of the common Data Abstraction patterns and principles you will see around.

• For example, you can think about Active Record , where you have your business objects, with its fields and methods, and also all the method related to the persistance (read and write from database).
• Also, you can think about a lightweight object, and save instances into and retrieve them from the database by some other object which gives mapping capabilities, such an entity manager, like some ORMs do.
• You can also take a look a Zend TableGateway that its a cool approach to representing database tables as objects, that you an migrate to android and sqlite.
• You can use a simple and yet powerful solution based on hydrators, as I explain below

Personally, what i prefer is to use Hydrators

This is a concept widely used in some ORM, also in native Zend Framework, and in other systems to provide data persistence, this is, to help objects or even web forms to be mapped to database records in an easy to understand and to maintain way.

A hydrator is an object that maps the database field names on one side, to the entity properties on the other. It doesn’t store this information internally, but provides mechanisms both for creating objects from databases, as well as extracting datasets from objects to update the database.
Is something that can start as easy as an object with an array of Column Names -> Entity Properties, and when its YourClass hydrate() method is called, will transfer the respective information from the datasource to the model object, and when the extract(YourClass yourObject) method is called, it transfer the data contained in yourObject to the corresponding database record

I like this approach a lot, since it is really easy to create an Interface, and several implementations for common use cases. So you can perform changes in your database without affecting the main objects, or the helper. Also, using the same interface, you can create mappers to exports your data to json, xml, rest calls, or whatever other stuff you can imagine.

If you can think about a good hydrator desing, and then create some classes to inherit from, you can have a really small databasehelper, really small entity objects, some abstract classes doing common work, and some concrete hydrators that can get all the weight you could need, but never that much since you can have one for every table or object type, so the classes are obviusly smaller, and moreover, they only contains code that is related at a business level.