Are you still writing Add/Edit/Delete code?

Recently one of my programmers came to me after having visited with a PDSA client. He told me one of the programmers at this client was creating a new .NET application and had about 5 add, edit, delete screens created. He had spent, on average, about 7 hours creating, testing, debugging and tweaking the code on each screen. He wrote a little over 200 lines of code for each screen and at least 5 stored procedures for each screen as well. Even though he was able to copy and paste a lot of the code from one screen to another, he still had to fully debug and regression test all the add, edit and delete routines on each screen. This was in addition to the business rule logic that he had to test.

So, what is the point of all of this?

Why was this programmer (and maybe you?) not using some sort of code generator and Framework to generate all of this CRUD (Create/Read/Update/Delete) logic? If you are not using a code generator to create add, edit, delete and simple business rule logic for data, in my opinion, you are spending WAY TOO MUCH TIME CODING and NOT ENOUGH TIME SOLVING the business problem.

The problem with hand-written add, edit, delete code can be summed up fairly succinctly:

  • It may not be standards based (give a CRUD screen to 10 developers and you will most likely get 10 different versions).
  • It is difficult to reuse for the next application.
  • When it needs updating, someone will have to search through all those lines of code looking for locations to update.  Guess what?  They won't find all of them, resulting in high error rates.
  • This code will be harder to maintain over the life of the application, as new team members replace the original coding team.
  • It has to be written and re-written any place you need to add, edit, delete the same table, even on different forms.
  • If you change the table schema, you will need to find all the places where the add, edit, delete code for that table is and modify all those locations. This is a very error prone process.

You can eliminate every one of these consequences if you take advantage of a good Framework and Code Generator.

NOTE:  Many frameworks are NOT worth the hassle.  Microsoft's Enterprise Library, for example, has so many downsides (no support, high learning curve, bad documentation, no upgrade path, way over-engineered, hard to use just one block by itself), it is used at the peril of any developer.

So which Framework should you use? It depends! I know, not a very good answer, but there are so many different frameworks and code generators out there that it is hard to find a one-size-fits-all. As far as code generators go you can't go wrong with CodeSmith (http://www.codesmithtools.com/). This will help you generate CRUD logic quickly and simply.

As far as Frameworks, some are good and some aren't. What you need to look for are the ones that do not lock you into their way of doing things:

  • Once a Framework generates code how customizable is it?
  • Can you inherit from their base classes?
  • Can you override their methods?
  • Can you add your own code to the generated code?
  • Do they separate their business logic from their data access code so you can add on your own business logic and not have it wiped out when your database schema changes and you need to regenerate?

So many questions, and so few answers. You will need to ask these questions before purchasing a Framework.

Many people have asked me what we use here at my consulting company PDSA, Inc. (http://www.pdsa.com/). We built our .NET Framework and Code Generator from scratch! I know, a lot of work, but it was worth it. We now have a process in place that is consistent from developer to developer. We have all CRUD logic generated in literally a few seconds. This includes all stored procedures. The code generated is also 100% bug free! This means we do not need to test any of this code. We only need to test the custom business logic we need for those particular screens that we are coding. This eliminates hours and hours of work. If the table schema changes, we simply regenerate, and since our business logic is separated from the CRUD logic, our custom code is preserved.

So, how does our Framework and Code Generator work? I do a monthly webcast that shows you our Framework. Sign up at www.pdsa.com/webcasts.

Please understand I am not on this blog to promote our stuff. I happen to believe in Frameworks, any Framework, and I believe you owe it to yourself to check out the myriad of Frameworks that are on the market. I have been developing and designing Frameworks since I worked on COBOL on the mainframe. When I was doing Clipper programming I designed a code generator, screen painter, and a process for creating CRUD logic. In VB 3.0 I created a code generator and starting with VB 4.0 I have had a more complete framework. That has then led into our PDSA .NET Productivity Framework that we sell today. So stop writing so much code and focus on the business problem at hand. This will make you a better developer and one that is more demand by employers.

Paul

10 Comments

  • CRUD code accounts for maybe 10% of the app we offer here at work. And yes, it's handwritten. I don't think I would've saved any time whatsoever using code-gen.

    Some of the CRUD stuff is also pretty complicated. We're way past "update one table with one stored proc".

  • I absolutely beleive in CRUD. I use SubSonic.

  • I use SubSonic to generate the DAL, love it. Saves an enormous amount of time.

  • IMHO -You shouldn't make the client dependant on your internal development tools. Having been burned in the past by this, I wouldn't accept code any other way. I'd much prefer you were using commercially available code generation tools.

    I wouldn't even accept the source to your internal code generator - that means I'd have to pay someone to learn how to use it in the future. I think using a publicly available and supported commercial code generator is the only way to go.

    I like the rest of what you had to say.

  • Dave T,

    We are mostly doing work for clients that have no IT staff, so we are the ones that maintain the code, thus we need to have a process that is repeatable.

    Our code generator and Framework is a commercial product and is supported. So either way, whoever were to take over the code would have to learn one or the other.

    Good points though.
    Paul

  • Hmm... Look, I earlier used ".NET Tiers", a free codesmith template, and it worked good for me. IT used SPROCS, so, I had too many SPROCS in the DB, but it was OK.
    Now we use "LLBLGen", that's such a great (yet a bit expensive) solution that's just worth the money. We use it not only for CRUD work, but to encapsulate all our SQL stuff. It has typed code for SQL queries, as it uses dynamic SQL (like LINQ, still encapsulates SPROCS too), has it's own studio where you can customizae the code generation to very far limits, and it can prefetch multiple levels of related entities very easily.
    Though, LINQ should change the way we think about O/R mapping I think.

  • One problem with these code generator is the chainging technology. The technology for data access and bll are changing every 2 year. If you dont believe me , look at these layer in your own work 2 year back, 4 year back and 6 year back. The change is so significant you also need to continously evolve with the code generator other wise you will stay with the same code that you were using 6 year back

  • Not only code generators, but all coding changes over time. Frameworks change, methods for how we do things change. Remember until .NET 2.0 hardly anyone was using the Provider model, now that is all the rage. There is nothing wrong with using a code generator. If it gives you the flexibility to change with the changing times, then you take advantage of that. Most code generators use a scripting language, and thus you should be able to change the code for your new techniques as time goes on.

  • LLBLGen all the way here.

    Saved me a few centuries of work.

    Not only has it saved me enormous amounts of app code, but previously I was writing sprocs for CRUD. Now I'm down to zero sprocs for most of my development projects. They just aren't needed since LLBLGen came along.

    It has a very steep learning curve though, IMO. But well worth it. I can never go back.

  • Using code generator for the simple parts of your application is good ( using them for database tables which only needs simple add delete update and less or no business logic) however for all other business logic and components hand written code is much better...

Comments have been disabled for this content.