I am coming from backend environment in PHP into desktop in AIR and trying to grasp the new concepts.
In PHP when I am accessing a database I would usually write a database-augnostic connection class so others, like DataMapper or ActiveRecord pattern classes can seamlessly connect to it regardless of DB implementation. This DB-augnostic connection has a propery which points to a DB specific class (mysql, mssql, postgre, etc.) so then DB backeds can be swapted without affecting the application.
When I am working in Air, however, I only see an Sqlite implementation by SQLConnection class. I do not see a way to change this type if, for whatever reason, I want a different embedded database engine (and the app will never interface to the internet). If Air does not support other embedded DB vendors, I do not have much problem with it, but then there is no point wasting time writing DB-augnostic adapters; I can go straight into data management.
So my question is, should I bother separating DB engine layer through adapters in Air or there is only one choice in the first place and I can code to Sqlite directly.
There is only one choice right now. We do have a feature under development that would allow extensions written in native code to be added to an application. That feature could be used to provide a different database implementation.
Thank you, good to know.
Will the new implementation be abstract like, say Zend Framework, where I write to Zend_Db_Table class in a generic syntax and ZF does convertion to native code of whatever engine I picked in main configuration? Or should I create DB abstraction layers manually between Value Objects and database engine in preparation for that new feature?
Is it too early for you to answer these question?