Probably something you're not thinking about is the UX.
Too often websites mirror their database in terms of "here is a CRUD form that maps around a table in our db". That's the way it is for a lot of websites but a lot of research is showing how it's poor UX
Have a read about task based UIs. Rarely does someone want to read a form and edit one field, or two fields. They want to perform a meaningful business action which should have a specific form for it.
The reason I mention this is that it probably doesn't fit too well in your model. Not to discourage you! You're right that a lot of websites are how you describe, but it would be great it if we could move away from that!
Slight nitpick
some middleware to do business/database
"Middleware" generally should not be doing any business logic. I would not expect my middleware to be responsible for saving the form entries into databases.
Saving fish by writing code! Applications developer in fisheries, specializing in webapps and moving 'enterprise-y' legacy systems to modern agile systems - Email or tweet me if you want to talk!
I mostly implement task based UIs at the day job, but baby steps. I'd rather see if there is interest in a framework that can be given a form and create a backend first, before a framework that can be given forms, and create a backend, and then manage the finite state machine inherent in task management.
Saving fish by writing code! Applications developer in fisheries, specializing in webapps and moving 'enterprise-y' legacy systems to modern agile systems - Email or tweet me if you want to talk!
Probably something you're not thinking about is the UX.
Too often websites mirror their database in terms of "here is a CRUD form that maps around a table in our db". That's the way it is for a lot of websites but a lot of research is showing how it's poor UX
Have a read about task based UIs. Rarely does someone want to read a form and edit one field, or two fields. They want to perform a meaningful business action which should have a specific form for it.
The reason I mention this is that it probably doesn't fit too well in your model. Not to discourage you! You're right that a lot of websites are how you describe, but it would be great it if we could move away from that!
Slight nitpick
"Middleware" generally should not be doing any business logic. I would not expect my middleware to be responsible for saving the form entries into databases.
Good luck!
I mostly implement task based UIs at the day job, but baby steps. I'd rather see if there is interest in a framework that can be given a form and create a backend first, before a framework that can be given forms, and create a backend, and then manage the finite state machine inherent in task management.
middleware is perhaps the wrong word. I mean the "middle layer"
this:
UI
Everything in the middle
Database