Every developer knows what CRUD stands for. Its an acronym for (C)reate, (R)ead, (U)pdate, and (D)elete. Dealing with CRUD is one of the most time-consuming tasks in a Web developer’s day. Combine that with website styling process and you get at least 50-60% of the development time spent on each site, on average (at least that is my experience).
You can use any number of frameworks or approach a problem from any number of angles, but the CRUD is always there. And every time we use it, it is like we’re reinventing the wheel. We struggle with all those $_GET and $_POST, if, switch, else… (and so on) statements over and over again, but it often feels more like a waste of time and resources more than anything.
So, what do we do? When most developers need to write something to database tables, or make a update interface for some table, we write down the custom form for it (including the CRUD). On one hand, it keeps our skills sharp. But on the other hand, it’s time we could better spend on focusing and developing additional features, bug-fixing our applications, and so on. But the CRUD is relevant as well.
CRUD is almost always important at the user interface level of most applications. For example, in address book software, the basic storage unit is an individual contact entry. As a bare minimum, the software must allow the user to:
- (C)reate or add new entries
- (R)ead, retrieve, search, or view existing entries
- (U)pdate or edit existing entries
- (D)elete existing entries
Without at least these four operations, the software cannot be considered complete.Because these operations are so fundamental, they are often documented and described under one comprehensive heading, such as “contact management” or “contact maintenance” (or “document management” in general, depending on the basic storage unit for the particular application), but they are really just CRUD.
So how do you deal with it?
PHP has numerous frameworks, meaning numerous philosophies of building a website. Personally, I love frameworks because they establish order in the midst of chaos. And, although some of these frameworks can help you avoid CRUD, it is worth considering the price you will pay by using these solutions.
Recently I came across Doctrine. Not many developers know about the term ORM. Hard to imagine, but true. So what is ORM? ORM stands for Object Relational Mapping, and it’s a promising concept that is slowly becoming popular for developers. One of the best features of ORM is that it can help us greatly when we are in need of dealing with many relational tables. However, ORM does not solve issues with CRUD because it uses somewhat complex configurations to solve the same problems. A solution that truly saves time with CRUD has yet to be developed. So, we return to the same CRUD again and again. There simply does not seem to be a flexible, fast, and easy (two or three lines of code) solution to map and auto-generate all the necessary fields from database to form.
But I’ll keep looking.
Feel free to post your thoughts, ideas, and solutions on dealing with CRUD problems.