A typical set of data-entry forms and search-and-view screens and reports. "Crud" stands for CreateReadUpdateDelete information, often but not necessarily tracking the database schema one-for-one. The term is often associated with, but not exclusive to "business applications".
While many business applications may have need for such screens, it is often a CodeSmell when an application is principally composed of such screens. It often indicates that the DomainModel has been neglected, pushing the business logic up into the GUI layer or the end-user.
Also recently known as [a specific paradigm] by those who think this is programming.
That is not true. CrudScreens can be and are generated in many paradigms. The user cannot tell which paradigm it came from for the most part. This topic is mostly about user requirements, not languages nor language paradigms to bring them about. Perhaps specific scenarios can be brought up. Well, actually I can name one: In MicrosoftWindows one often must use the GUI to make certain configuration changes. There is no API or scripting command to automate it. This generates repetitious busy-work for larger organizations. However, "regular" end-users are not going to be doing most of their work via command scripts such that the GUI interface is necessary even if scripting is an option.
I think "list" should also be included, but perhaps that would be under Query, which is perhaps not meant to be included.
Query is a Read.
Yes, but often it involves fairly complex input to get the desired query that I think it deserves its own category. But I guess the term is too entrenched to adjust now.
Features that typically need to be considered in CrudScreens:
One of the eternal HolyWars surrounding CrudScreens is whether to use coordinate-based element placement or flow-based (hierarchical) placement. (But this is a wider UI design debate; see CoordinateVersusNestedGui.)
I don't see where the CRUD acronym comes in. The "too many operations" implies that there is not correspondance with "create, read, update, and delete".
The correspondence comes from the fact that one writes 'C', 'R', 'U', and/or 'D' in each of the cells of a CrudMatrix, representing which of these operations the procedure performs on a table.
CrudScreen work is often stereotyped as being boring and repetitive. (See DomainPissingMatch). However, anything that is boring and repetitive should in theory be relatively easy to automate. Over the years I have been kicking around ways to simplify and automate the process of crud-screen creation by playing with experimental frameworks, both implemented and conceptual.
However, a sufficient system/framework still seems elusive. It is not that they are simple by themselves, but that patterns in them are common and familiar. As an analogy, one might look at all the different car makes on the road, think about the similarities of cars in general, and wonder why the parts are not more interchangeable rather than custom-made per model for the most part. Part of the reason is that technology keeps changing too fast for standardization to catch up, and partly because marketing forces push each model to be unique to "stand out". Similar forces are at work in crud-land.
Here are various observations I have made about automating or simplifying CrudScreen creation:
Unfortunately I haven't found anything that automatically generates these for Web/Java development besides Apple's excellent (but proprietary) WebObjects / Direct to Web. Any suggestions?
You may want to take a look at: CodeGenerationIsaDesignSmell or, if you really really like CodeGeneration, perhaps SeamFramework or AppFuse can help you... or if you one DynamicOnRutimeApplicationGeneration? (like that of Direct to Web) then you should take a look at the NakedObjects
I've been looking for a less quirky acronym or phrase I can use for these screens I can put on my resume. Anyone have any ideas? --ChrisMellon?
Human resources is not going to know what "CRUD" means most likely. Thus, maybe just put something like "interactive business forms".
We used to call it "ExBase". Put a picture of the database on the screen and let the user fiddle with it. It lets you deliver an application without worrying overmuch about how it will be used, without wasting a lot of time talking to the user, and without actually having to do any design. --AnonymousDonor
Coming soon to a book store near you: "DBase for the debased" (SCNR)
Somebody trying to start a fight? (See ExBase)