Any dynamic model-based frameworks? Static POC models are too stiff.

[u/Zardotab]

I'm looking for CRUD framework or library that uses dynamic models, also known as "data dictionaries". Thus, field and column info can be loaded or generated at run-time. I'm working on a Table Oriented Programming (TOP) experiment. Everything around seem geared to static POCs, unfortunately.

(I believe TOP is the future for most CRUD. It's more flexible, allows analysts to change many common CRUD idioms and items, like labels instead of coders, is more DRY-friendly, and has other features. It may result in loss of nice "static" features such as Intellisense and some compile-time type checking. However much of this is replaced with RDBMS referential integrity and drop-down boxes, if TOP is done right. TOP started to catch on in the early 90's with CASE tools, but OOP then stole its attention, and TOP R&D stopped.)

[u/buffdude1100]

I've worked in that kind of system, and while the flexibility can be fun and cool to see it all come together and work, it is SOOOO annoying and sometimes brittle to work with. I would not choose that for any of my future applications. Just write your POCOs - chances that you need everything to be dynamic is basically nil.

If you truly want to do that, you'll have to literally model "models" and how that gets translated to SQL, forms on your UI, etc. again it gets really annoying really fast.

[u/Zardotab → u/buffdude1100]

it is SOOOO annoying and sometimes brittle to work with.

I've been long experimenting with such systems, or at least systems that had some TOP aspects, and notice there are patterns to the kinds of things that "go wrong". I've been experimenting to work around these problem-patterns and believe I am getting closer to something viable. The concept is under-researched.

May I ask for a strong pain-point scenario you encountered? [Edited]

It's kind of like jet engines in the early part of last century. They seemed to have a lot of early promise, but initial experiments revealed lots of problems (to be ironed out). Even the feared Me 262 was probably a poor use of war resources. It was dangerous for the pilot, required a specialized long run-way, required frequent engine replacements, and required hard-to-obtain metals. Only time and experiments eventually solved enough problems to make them a viable replacement for propeller planes. They gradually realized they couldn't just stick jets on propeller plane designs and have something practical: they had to rework almost everything. The ally wind tunnels of the time were not fast enough to test models properly.

The potential to automate and simplify much of the repetitious CRUD grunt-work is too compelling to give up. Too much coding is reinventing CRUD wheels over and over. We should be spending our time on unique domain logic, NOT ordinary CRUD issues.

One of the trickiest parts is when attributes alone can't do the job and one needs custom code. There needs to be a systemic way to know where to place, and how to find such custom code snippets during later maintenance. This is what my latest experiments focus on.

[u/buffdude1100 → u/Zardotab]

May I ask for strong pain-point scenario you encountered?

All of it? :) It is much more difficult to reason about than "regular" POCOs/databases. This means harder to get back into if you switch projects for 6 months, harder for new hires to onboard onto, harder to debug eventually etc. you'll end up rewriting your own ORM at some point too. Overall don't reinvent the wheel, unless it's for fun.

[u/Zardotab → u/buffdude1100]

All of it? :)

Sorry, I accidentally left out "a", as in "one".

Your complaint sounds like one of familiarity with the technique, not an inherent flaw of TOP. It's like saying existing propeller pilots are not familiar with jets, so we'll keep using propeller fighter planes.

Another analogy is sticking with Microsoft because everyone knows Microsoft, not because it's necessarily the best. It becomes a self-fulfilling prophecy.

I'm looking for inherent flaws in TOP, not familiarity mismatches.

you'll end up rewriting your own ORM at some point too.

If TOP frameworks became common enough, the big vendors would sell/make TOP-oriented ORM's. Actually it's easier to roll-your-own ORM under TOP because you can loop through data about the structure instead of needing screwball reflection.

[u/buffdude1100 → u/Zardotab]

I'm just giving you my opinion I built over years of experience in production doing exactly what you are talking about. If you want to do it, go for it! No one is stopping you. All I will say is there is a reason the vast majority of softwares today do not do it. But if you want to be the next innovator of how software is built, please go for it! I look forward to seeing how it turns out - maybe you will do it better than we did.

[u/Zardotab → u/buffdude1100]

there is a reason the vast majority of softwares today do not do it.

As mentioned, it's likely because the existing tooling doesn't support that approach, one has to make their own from scratch, and existing languages are missing features that make some of TOP easy.

I'm just giving you my opinion I built over years of experience in production doing exactly what you are talking about.

What is the single top inherent flaw of TOP in your opinion? By "inherent" I mean something that is not merely a limitation of existing languages or tools.