ThoughtFactory.CreateThought() A random collection of thoughts from an easily bored developer

Your Application is CRUD!

How many times have you heard that a tool will save you heaps of time because it automatically generates some sort of CRUD layer for you? Depending on how good you've been for Santa you could get a generated data layer, service layer or even an entire application. Great! More time for coffee!

Well, yes and no.

Most of the CRUD frameworks organise themselves around the concept of creating, reading, updating and deleting a record in a database table. Administrative functions that exist to keep the actual line of business operations ticking over tend to fit this scenario perfectly. So now we have a bunch of frameworks and tools that can help us generate our generic record administration (users, customers etc) and reference data maintenance modules. What about the rest of the application?

Deciding to develop a CRUD Orientated Application (I can't believe I just coined the acronym "CRUDOA") lets you off the hook with regards to many important design decisions. You don't have to care about user experience or business process improvement, because your approach has already been decided. One thin facade around the database coming right up!

Most business users are concerned with performing business functionality. This usually takes the form of some sort of operation or work flow step that forms part of a larger process. They don't care whether the operation creates a record in 1 table or 40. This is usually where the aforementioned business process improvement and user experience analysis is required to make sure that your users don't end up throwing their monitors through the window in frustration.

Obviously if you have any desire to avoid having rotten fruit pelted at you by disgruntled users then you're going to want to put some thought into how they use the system. A generated framework that only has one paradigm (that of editing a row in a database table) greatly restricts your ability to do this. This effectively puts a generated CRUD layer out of the running for any part of the system that is not solely concerned with record maintenance. Then again if you're a developer working on Toad or SQL Server Management Studio then your entire system may consist of record maintenance, and you can probably stop reading this post as large portions of your system will be orientated around exactly that.

So if the real meaty bits of line of business applications are not suited to CRUDOA then why are we constantly looking for ways of aligning our architecture along that path? Why would be use a CRUD data access layer if we rarely perform CRUD operations? Why would we generate a CRUD service layer and UI to feed into that CRUD data layer if it's not a suitable paradigm?

We do this because the tools generate the code for us, and generated code is awfully tempting to use. After all, it's sitting right there and all you had to do is press a button to get a large section of functionality for free. Only it's not actually free, because our requirements often force us to stray from the golden path offered by the CRUD tools, meaning we then have to spend a large portion of our time trying to shoe horn a domain operation or cross entity transaction script into a CRUD approach.

The good news is that a lot of the tools only generate CRUD as a default. There's no reason you can't create an operation-orientated Rails site. You also don't have to accept the default SQL that is generated by your favourite data access layer. The defaults may be attractive at first, but unless we're happy to stay on the golden path (and end up with a mediocre application that has no user buy-in) we are going to waste time trying to stick a square peg into a round hole by modifying the CRUD framework to be, well, not CRUD.