MVC and CRUD Learnings
I have been working on https://www.aleckornblum.com and following the documentation of https://htmx.org. They advocate for a hypermedia approach to reduce the reliance on Single Page Applications (SPA's), which require JavaScript proficiency to develop.
However, what they describe (a hypermedia approach), is an alternative
they enable with the htmx tool. It embraces the original principles
of the web while providing just enough JavaScript (AJAX) code to allow
a server-side interactive web app.
While coding more functionality into my website, I've come to some realizations regarding CRUD and MVC.
MVC is not a GUI framework
MVC is not just a framework for GUI creation. When seeking resources
to learn about python GUI development, you might commonly find MVC
represented as an object-oriented method for using tkinter or
PyQt5 or wxPython.
However, it is very clear from reading https://hypermedia.systems that
the exact same principles a tkinter MVC application should be using
are contained in the hypermedia approach.
The hypermedia approach has the advantage of simple, built-in methods (pun intended) for the MVC approach.
MVC is not a set of three files
MVC stands for Model View Controller. However, it doesn't refer only to a database with rows in it, a file called controller.py (or controller.lisp), and a BlahBlahBlahView oject.
The MVC framework is a standard way to expose the persisted data of an application safely. It is the way every application connects the user to the data. Some of the key aspects of each of the parts of the framework follow:
Model
The model is more than just the database. It is indeed the database (or whatever method you're using to persist data). However, the database is not easily and safely accessible.
When developing an application using the MVC framework, one of the first profitable steps you can take is to quickly mock a database. I have had success using basic in-memory data such as a python or lisp list. Another way to do it is to describe your data and quickly make up some fake data in a real database table. Sqlite is essential for this.
Once you have that data, then you can create functions that query the
database. At the point those functions work well, your Model has been
implemented. For a table of users, it's useful to have functions like
read-user, read-users, update-user, delete-user, and
create-user.
Obviously your mileage may vary if you're using an ORM or another object oriented approach.
View
In a hypermedia application, this is the html that renders to the screen. With GUI applications these are widgets on a canvas or root application.
Controller
In hypermedia, the controller is the route that the server responds to. It renders HTML and the hypermedia client responds by replacing the old the page (or with AJAX, some of it) with the new HTML.
The proper order of CRUD is RCDU
For ease of hypermedia development (let alone any other data application) the CRUD operations should be created in a particular order. I assert the proper order is RCDU.
Once the data source has been initially configured or mocked, the Read aspects of MVC (database functions, views / templates, and routes) can be created easily.
After that, the most optimal set of MVC to create is the Create. This is because it's wiser to be able to add to your (mocked) database before you delete from it. Having this in mind should solidify focus of development as well and allow for more streamlined development time.
After create, the Delete MVC is next simplest.
Lastly the Update MVC should be a breeze using the read, and having full access to the rest of the CRUD MVC's.
CRUD is the easiest way to remember the four typical aspects of data-driven applications. However, RCDU is the proper order in which to develop them.