I’ve just watched the ‘Using SQLite’ webinar and I think I now understand how to create/use an SQLite DB. Great video. 
Question though: Where should I add my ‘DB’ Property? I ask because the video shows it being added at the Window level (desktop app) and then being passed as needed to other windows. Could I add the DB Property to the App (rather than window) and then just refer to it from anywhere in my App?
Thanks in advance.
Personally… I would create a module for all the DB related items, and put it there…
I am of the opinion that very little should be put in the APP object itself… but then that is my opinion
Thanks Dave.
Hello,
if your application will be able to open multiple databases at the same time (so that each open window of your application displays the data of an other database) then you should add the ‘DB’ Property at the Window level.
There is no difference between using App for a database property or a module, it is a decision of taste. But both introduce global state into the application. The property is accessible from everywhere and therefore will be accessed from everywhere.
Stop reading here if you do not care about global state (in a lot off smaller applications it does not really matter).
This is a possible approach for avoiding global state:
Subclass the specific SQLiteDatabase, MySQLCommunityServer, etc. class and add everything related to it in that subclass.
Create a private computed property Database As MySQLiteDatabase in App. The setter stays empty. The getter has this code:
// creates one instance only, the first time the property is accessed
Static db As MySQLiteDatabase
If db Is Nil Then
db = New MySQLiteDatabase()
End
Return db
As the App’s Database property is set to private, it can not be accessed by the rest of the application directly, instead one needs to hand it over to each class using it. So every class, every window, etc. has a constructor, which contains (besides others) a parameter db As MySQLiteDatabase.
The advantages:
Makes testing classes easier, since all dependencies (not only the database) must be handed over in the constructor. It is nearly impossible to test a class which depends on public properties in App or modules and where your code within the class has lines like If App.Database.Connect() … or MyModule.DoSomething().
Makes using classes in a different project much simpler. You just copy and paste the class. You will not be able to compile until all constructor demands are satisfied. Once they are satisfied you compile and the application works. With global state you would need to change all lines of your class to access the global variables before being able to compile. Not using global variables also means one does not have to check if all the global variables are initialized to non-Nil when you need to use them in a class. Just check once for non-Nil for each argument in the constructor.
The “mental image” of the application in term of the dependencies within a project changes from a complex graph to a series of function calls. Like App > choose Sqlite file > login as user > select company > open contacts window > … Instead of App > choose Sqlite file (uses DBModule) > login as user (uses DBModule and UserModule) > select company (uses DBModule and UserModule and CompanyModule) >…
Each class, window, etc. has one entry point, the constructor, and one exit point returning one or several values (I always call it Close()).
[quote=335491:@Christian Mézes]Hello,
if your application will be able to open multiple databases at the same time (so that each open window of your application displays the data of an other database) then you should add the ‘DB’ Property at the Window level.[/quote]
Or set your db Property a bit more meaningfull than simply db. Say, Acme_db, Bell_db, etc.
Eli,
Many thanks for your detailed explanation. I have chosen to go with a globally available DB Property in a Module (DBModule). So far this seems to work for my rather simple Windows Desktop application and as I am just learning XOJO, I think I’ll continue down this path until I hit a wall. Again, many thanks for taking the time to fully explain the whole ‘global’ thing … it’s much appreciated.
Hello, that’s a good suggestion. What I meant was a document based application (for example something like Filemaker or Excel), where one can open/edit mutliple (database)files at the same time and each file is displayed in its own separate window. When I am developing such a document based application I put the database-property into the window.
And where do you place the db read / write methods (etc.) ?
Hello, currently I put the methods which do something to/with the database into a module that I call DatabaseModule. I use that module in multiple apps. I also have classes in that module which represent database columns tables etc. so for example a table is aware of its own columns and also the properties of the columns etc. In a document based application each window has it’s own myDB (as SQLiteDatabase) property and then for example if the user wants to delete a couple of columns from the database I write in a method of the window: DatabaseModule.DeleteColumns(myDB, theTable, theColumns). Of course there are other ways to solve this problem but this somehow grow naturally over the years.
PK.