Table and Query Classes good or unnecessary?
On 5/3/18 4:08 pm, Clifford Ilkay wrote:
> I was reading an article recently about how ludicrous it is that we are
> still having the same fights over which is better, functional programming
> or object-oriented programming. The funny thing is that the OO camp isn’t
> uniform in thought either. They have spirited debates over inheritance vs
> composition with some languages or frameworks favouring one or the other. I
> see merits and shortcomings in all of them.
Exactly, every approach has pro’s and con’s, you need to weight them up
and decides if the pro’s of an approach outway the con’s for your
Skillset is an important factor in this. One of the things that has
always surprised me in a really positive way is the type of people I
meet at conferences like EurOmnis. Many aren’t “programmers” in the
traditional sense but come with a business background, having a need in
their business to automate something and finding in Omnis (classic) a
development environment that allowed them to do so without obtaining
“programming skills” (in the traditional sense.
I’m not convinced by a long shot that that caliber of developer
necessarily finds a lot of pro’s in object orientation. As good as it
has served me, and as much as I love it, I fully believe it is not the
right tool for everyone.
I’m doing more and more in game programming and engine building and you
see the same move here but much further along. More and more developers
who make games aren’t programmers by a long shot. They are artists, game
designers, people who have a passion for games and the market is
reacting to this. You see more and more the programming being taken out
of making games and more and more a visual approach to putting logic
> It seems like query classes provide a higher level of abstraction so that
> you don’t have to think in terms of rows, columns but you’re thinking of
> Omnis objects. If you could forget for a moment that you, or someone else,
> created those query classes by encapsulating SQL, you could say that Omnis
> has an ORM. Creating an ORM is well within the capabilities of engineering.
> Providing that level of abstraction so that you, the Omnis developer, would
> only have to think about persisting, fetching, updating, deleting Omnis
> objects without having to touch or even know about SQL, though you would
> have the option of doing that if you wanted to. That suggests to me that
> this high-level abstraction could be the same regardless of whether the
> back end is Omnis NDF, some SQL database, or even a NoSQL database. You may
> want to request this an Omnis enhancement. 🙂
I believe what query classes seem to be and what they really are, are
two things entirely different. I created most of the ORM logic on top of
table classes but I’m not at a place where I’m moving away from my
application knowing about the database structure and communicating with
the database on a higher level.
I don’t solve this in Omnis, I think it’s the wrong place, the long game
is to do a lot of this in a middle tier but as a stepping stone I am
doing more and more on the Postgres side either with views and rules
(rules are so cool you can treat your view like a table and insert into
the view, running logic instead that updates the relevant tables) but
nowadays more and more with JSON.
I’m sure I’ve mentioned this before on the list but I simply have
functions like listInvoices, getInvoice and setInvoice which either
return or consume JSON. My Omnis application hasn’t got a clue my
invoice is stored in a header table, a detail table, some tables
governing tax, some tables governing payment information, etc.
It also means that in my setInvoice function I can do all checks and
ensure an invoices is properly handled within one transaction.
Eventually I want to move most of that logic into a proper middle tier
so it can be better scaled but seeing my Omnis client now consumes JSON,
whether it gets that directly from the database or from a middle tier,
is a small difference to the client.
This is where I do start letting go of table classes. I would still
heavily use them if I decide to write my middle tier in Omnis, which may
very well happen depending on the steps Omnis Studio will make in the
coming months, but which could be in another programming environment all
together with just the front end being Omnis.