I agree some kind of event-driven architecture is ideal for typical business & admin CRUD. However, our existing languages and toolsets seem a poor fit and I've

I agree some kind of event-driven architecture is ideal for typical business & admin CRUD. However, our existing languages and toolsets seem a poor fit and I've yet to see a good one. They force things into hierarchies and make it hard to search and manage events outside the official hierarchy. Relational is more powerful than trees, so we should find a way to leverage that. I'd like to see languages & IDE's that assist some form of "Table Oriented Programming" (TOP) were either the event snippets are stored in an RDBMS, or at least the RDBMS is used by the IDE to search and manage the myriad events. Then can search and view by SQL and SQL-bases query tools. Developers wouldn't be forced to think in trees. Here's what a typical generic event handler table may resemble: Event (table) ---------------- ID Area // general app category Entity EventType // Search, Listing, Add, Edit, Delete, Process, other Stage // Ex: initialize, loadTemplate, adjustTemplate, preQuery, postQuery, submit, queryErr, failedValidation, passedValidation, preDisplay, postDisplay Tags Version SourceCode // Actual code or a pointer/link to it. In most cases the defaults or other attributes would be good enough such that explicit coding isn't needed, and thus most coding would be for specialized things. // Sample event function/method pseudo-code Public void AAA_EEE_TTT_SSS(EventState ev) { ... if(problemX) { ev.statusOk=false; return; } ... ev.statusOk = true; // final status of event } Where AAA is the area name, EEE the entity name, TTT the event type name, and SSS the stage name. These four columns would be indexed for quick searching and grouping. Under the hood it may still use the language's preferred file trees for generating or saving snippets, but developers wouldn't normally have to know or care about that tree. I have been experimenting with TOP, but the R&D job is too big for me alone. I see and smell the potential power to automate most CRUD grunt work using TOP & events, but gluing it all together in a nice way is a work in progress. (I don't claim it's ideal for high-volume apps, but rather for those with intricate business logic and a medium load.)