3 ms·
Doing most of MVC via database?
The "MC" parts of "MVC" seem like they can be automated and better tracked in an RDBMS than as code for a good many CRUD-centric applications. The "View" could be left code-centric but the rest database-ified. I've been experimenting, but wondering if I'm not reinventing the wheel. Here's a simplified draft schema to kick around:
// Navigation tree and page relationship (table).
Navig: ID (PK), ParentID, Action, Crudtype, Model, Title,
Filter, SuccessPathID, Priority.
// (CrudType: Search, List, Add, Edit, Delete, Other.
"Filter" can be used to de-select columns as needed)
// Field dictionary table, roughly corresponds to table/view columns.
Model: ID, FieldName, Type, Title, Nullable, MaxLength, FilterCodes, Sequence
// Relationships to define drop-downs and/or read-only, per CrudType.
Lookup: ID, Model1_ID, Model2_ID, IDcolumn, DescriptColumn.
// Customized or specialized activity table, similar to event handlers.
Special: ID, PathID, Model, Action, FieldName, Operation, Param1, Param2, Param3.
// (PathID, Model, Action, & FieldName can be wild-carded as needed. Example Operation: "Phone" to format & validate phone-number columns.)
A lot depends on settling on consistent shop conventions rather than try to cover every CRUD style.
- PaulHoule 9y ago10 years ago I did some work on a system that had been around ten years. This system had the front-end done in Cold Fusion and the back-end in Microsoft SQL server. The CFML application did not do database queries or updates directly but rather worked through a set of stored procedures. Since then I've seen a slightly more fashionable architecture where a "web service" provides an API that is lot like the API provided by stored procedures, and then a front end actually serves a web site.
- tabtab 9y agoPerhaps this is a side topic, but I don't understand the seeming obsession with "web service" or microservice API's that simply mirror data calls. If they are automatically wired from meta-data (such as the "Model" table above), they are perhaps an improvement over hand-wired ones; but still, why have an extra "middle-man" layer that doesn't currently contribute anything? For one, it creates more potential security leak-points. Wait until there is a real need. Don't pre-bloat all the data calls for the 0.00001% chance your org merges with Netflix or China. YAGNI.