
Doing most of MVC via database? - tabtab
The &quot;MC&quot; parts of &quot;MVC&quot; seem like they can be automated and better tracked in an RDBMS than as code for a good many CRUD-centric applications. The &quot;View&quot; could be left code-centric but the rest database-ified. I&#x27;ve been experimenting, but wondering if I&#x27;m not reinventing the wheel. Here&#x27;s a simplified draft schema to kick around:<p>&#x2F;&#x2F; Navigation tree and page relationship (table).<p>Navig: ID (PK), ParentID, Action, Crudtype, Model, Title,
   Filter, SuccessPathID, Priority.
&#x2F;&#x2F; (CrudType: Search, List, Add, Edit, Delete, Other.
&quot;Filter&quot; can be used to de-select columns as needed)<p>&#x2F;&#x2F; Field dictionary table, roughly corresponds to table&#x2F;view columns.<p>Model: ID, FieldName, Type, Title, Nullable, MaxLength, FilterCodes, Sequence<p>&#x2F;&#x2F; Relationships to define drop-downs and&#x2F;or read-only, per CrudType.<p>Lookup: ID, Model1_ID, Model2_ID, IDcolumn, DescriptColumn.<p>&#x2F;&#x2F; Customized or specialized activity table, similar to event handlers.<p>Special: ID, PathID, Model, Action, FieldName, Operation, Param1, Param2, Param3.	
&#x2F;&#x2F; (PathID, Model, Action, &amp; FieldName can be wild-carded as needed. Example Operation: &quot;Phone&quot; to format &amp; validate phone-number columns.)<p>A lot depends on settling on consistent shop conventions rather than try to cover every CRUD style.
======
PaulHoule
10 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
Perhaps 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.

