Table and Query Classes good or unnecessary?
> 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.
I am in the same situation. In my opinion Omnis is currently not the right platform to build a middle tier for my application. It could become it though, but it depends on where Omnis is heading. For long the previous owners let Omnis slide and didn’t invest in the core. Now with the new owners they already demonstrated that this has changed, but what the new direction will be is not clear yet (for me at least). I have the same thoughts as you: I need to start building a middle tier, but I have been pushing the choice forward (glad I could) in order to see what Omnis is up to. If they will be building a good backend platform I will definitely be using that, otherwise I will have to select another language and just keep the front-end in Omnis. If Omnis makes the right choices (for me), it will save me a lot of work, but otherwise it just isn’t the right tool for where I want to go. If they just prioritize the JS client I will have to make different choices. If they focus on the fat cl
ient to build your UI and on a better backend platform I will keep it all in Omnis. I’m not sure though if they can progress on all three fronts. The coming year will be important for me I think.
Van: omnisdev-en [mailto:email@example.com] Namens Bastiaan Olij
Verzonden: maandag 5 maart 2018 23:28
Onderwerp: Re: 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 particular situation.
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 together.
> 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.
Manage your list subscriptions at lists.omnis-dev.com Start a new message -> mailto:firstname.lastname@example.org
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:email@example.com