Michael Caldera, a software engineer at The Internet Works development partner Everlution Software, on the use of the CRUD cycle to give both users and administrators privileges to create, browse, edit or delete online records when developing a database project.
The bootstrap phase of a medium to big project is usually very fast and most of the time people concentrate on developing the back-end functionalities without really taking the interfaces into consideration. This is because everyone wants to have the system up and running as soon as they can. But often this unavoidably leads to bad design and a final product that is entirely un-intuitive for the end user.
It’s a good practice, therefore, to follow standard conventions and paradigms when you design the system in order to improve the readability of the source code but also the flexibility and maintainability. CRUD is good example, giving you a set of interfaces that facilitate viewing, searching, and changing information.
The acronym CRUD stands for Create, Read, Update and Delete, which are the minimal subset of operations that can be executed on a resource. CRUD is a very easy approach to the development and it is at the base of the HTTP protocol.
Here are some of the reasons why using CRUD is a good idea:
Granularity of the resources and the actions
We should define every resource is the most granular way possible – this means that we need to define small objects and declare at least the four CRUD interfaces in order to model them. For example if we are working with a blogging platform we can define these resources: author, post and tag.
And for each of them define the CRUD interfaces. But what about when we have to link an author or tag with a post you may ask? Well we define another interface for articles that allows us to create the relation. It’s flexible enough to add as many actions as we want.
The granularity is very important because it helps developers to have a better understanding of the system, especially when it gets big. Furthermore, dividing everything into these small actions is very good for assigning different tasks to different developers; indeed everyone can concentrate only on one single resource/action and create a black box system.
Debugging with CRUD allows fast recognition
Debugging becomes more difficult if we have to analyse an action that implements more than one task such as adding and editing a resource. Instead, CRUD encapsulates every possible operation in its own action and allows a fast recognition of where the bug might be.
You will have to write more source code but…
Someone might think: “Yes, but we have to write much more code”. That’s certainly true but rushing out code riddled with bugs is a false economy. It will take far longer to debug it down the line. Furthermore, the CRUD paradigm always follows the same pattern because even if the resources are different, the actions on them are quite often the same.
CRUD can make testing easier
Testing a controller is not easy and sometimes not possible, but if we define CRUD interfaces we can define black box tests very easily. This is because we encapsulate all the logic in an action and we define an interface (i.e. REST) that can be easily called instead of having the view part.
In summary we should develop with a CRUD paradigm as much as we can, in this way we standardise the code and we can easily make some services (REST, SOAP, etc) available without the need to refactor pretty much anything.
controller: a class that encapsulates actions
action: a method of the controller that implements all the logic for performing a task
resource: any object that can be modelled