Do It Once

My career has followed a pattern where I learn something, often with great difficulty. Then I start writing about it, primarily because writing is a key part of my learning process. After I have written about it for a while, I usually am asked to teach on the subject. I usually take advantage of these opportunities because teaching is also a critical part of my learning process. Finally, I am tired of teaching about that subject and end up teaching someone to teach the course. Once I have finished the cycle, I don’t go back unless the subject changes or I change my mind about critical aspects.

One of my many problems is that I never really want to do the same thing twice. I would much rather go out and figure out something else. I like the challenge of figuring something out, but then I want to give it to my assistant, my partner, my friend, or my computer. When possible, my computer takes over the chore because then I am freed from the boredom of doing a repetitive job, but I remain in control of how that job is done. For better and for worse, people don’t follow my directions nearly as faithfully as computers do. Better yet, I might still be able to collect money for the work if my computer does it.

This is a very handy mindset to have when most of your income comes from automating processes and developing software. As any programmer will tell you, a program is a set of simple instructions assembled into exceptionally large structures. Much of the assembly is simple and repetitive. This is painfully true when it comes to databases, and every project has a database. In fact, the database is most of the project for most projects, and the code is painfully boring to write.

Fortunately, there are an increasing number of solutions to this problem. Most involve some form of code generation, and some code generators will generate complete applications. All are welcome, but I have gravitated to CodeSmith because it lets me do everything my own way. I know every line of code generated by CodeSmith does what I want, and I know each line reads exactly the way I want it to read. I also know that when there are errors in my code, they are almost never in code that was generated, they are in code that I wrote by hand.

When I change my mind about the way this code should look or perform, I work on the code generation template until the template generates code that matches the new evolved standard. Sometimes this is easy, but if I happen to have some kind of conceptual breakthrough, the change can be massive. If I let myself learn too much at any one time, the templates could implode. Fortunately, I learn slower and slower all of the time, but sometimes I read a dangerous book.

The last such book I read was Robert Martin’s Clean Code. After reading it, I became convinced that the people using my business objects should have to know database information like primary keys. Related collections ought to be directly accessible. This seems simple enough, but it is pretty revolutionary to someone who has built and managed dozens of database systems basing all of that on the use of keys.

Here is the difference. In the real world, a customer has accounts, and the accounts have deposits and withdrawals. In the database world, the customer record has a primary key. Multiple account records may share the same customer primary key, and each deposit and withdrawal would contain the primary key of a single account. There is nothing tricky or fancy in the database code to record a new deposit, but on the database level, all of this is done using the primary keys.

It’s been my practice and the practice of many others to export that level of detail to users of those business objects. Often, the person doing the database programming was also programming the application that called the database so it wasn’t like anyone had to learn something new about keys. However, it is clearly detail that ought to be restricted to the data access layer. Any time a web page or a Windows form needs to know about primary keys, details that should be encapsulated in the data access layer have leaked to the presentation layer.

This might all sound very easy once you really define the goal, but the goals always change during a project because the project is a learning experience. The templates become the place where I put what I have learned to work. The templates never stop.

By the way, my old CodeSmith templates for C# and SQL-Server are posted on at DbObjectLight. The new templates will be posted there as soon as I get time to document them. Anyone is free to download them and use them. Let me know if you have any problems.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s