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