Architecture of Object Model and Persistence in xojo


There are two approaches to create persistent object models. The first is to create domain objects, such as “Project”, “Milestone” and the like. And then have a second persistent “layer” store those objects in the database – in a way that is transparent (unknown) to the domain objects. With this approach, there is no storage related code (such as SQL statements) in the objects.

Another approach is to have a domain model which is essentially, a “facade” to a database. The objects really don’t store anything themselves, but everything is immediately written or read from the database.

Which approach is most commonly used in Xojo apps.

Are there any recommendations?

thank you,


I think the answer is more related to:
a. Single or Multiuser environment
b. OLTP or mostly read only character of the App
c. How generic the objects are and the DB schema
d. DevTeam: One man band or n members
e. Max amount of objects in one view
f. Individual App or a App on sale

and even the preferred paradigm. I guess you get more help when you describe the character of the App’s you plan to develop.
There are members here who do a lot DB App’s.

Hi Stefan,

Thank you for your prompt response and further elaborating the issue.

I have been going back and forth between the approach, at one time thinking more architectural structure is better and at another less is better. I have been influenced recently to more structure after reading about an architecture approach for information systems called QUASAR, which has quite a bit of predefined structure.

But I now note that it creates too much complexity at this stage, when the app is quite small, I now feel that I want to make the code as simple as possible. But, not too simple.

Because of that, I don’t put database code into UI event handlers. But, created “domain” classes that essentially are front ends for inserting, updating and selecting from the DB.

I would much appreciate a discussion about applications, architecture and Xojo … what the experiences are and lessons learned. Perhaps worth even a separate discussion “Channel” …



For Error handling etc. i would propose a general layer for database abstraction. Then i would create a Class and Interface for the generic pieces of data handling and than use subclasses with overriding where necessary. Both approaches reduce complexity while developing the logic and UI. The complexity in the abstraction layers are paying off when they evolve and nearly never get touched again when they are stable.

You can find several discussions about ORM etc. here, so just search and read i would say. Look for ActiveRecords and ORM.