So I'm one of those coders that is constantly trying to "refactor" my way of coding, if that makes sense... I have a natural assumption that i am not coding in the most ideal manner and the more blogs i read, the more I come to realize that I am not alone. A lot of coders out there are looking for a better way. The reason that we feel something is missing is because something is missing. The field of computer programming is in its infancy and I am excited to see what will be available in 20...50...100 years.

Fridays at my company involve me reading about coding instead of actually coding. I don't see this as a waste of time because I feel that in the long run I actually SAVE myself time. Take for example, the day I learned about O/R mappers. The 1st version of our company's bread and butter product worked with MS ACCESS as well as SQL Server. Being a brainwashed "recordsets are god" programmer (this was back in VB6 days) naturally we used stored procs and queries as access calls them. Schema changes were a nightmare and never occurred.

The application, although successful, had to evolve into where it is today. The fact that it was successful argues another point that being, the primary focus should be solving a business problem. Code "prettiness" is secondary. Nevertheless, as all applications must do in order to survive, we evolved. The next release of our version would be a complete rewrite (ut oh some might be saying) and yes I do know the cardinal rule of never doing complete rewrites, but .NET was just coming into mainstream and I felt it was time to abandon ship.

As we began the rewrite, I did not want to have stored procs ever again. I came upon NHibernate by accident. Time for yet another tangent.... For a long time in my development "career" I felt something was missing. The first time this happened was when I started reading all these Object Oriented Programming (OOP) books. They would talk about this domain model and how glorious it was, but the examples were always trivial. I'm not naive, 99% of line of business (LOB) applications involve an actual database (GASP!). I could not for the life of me figure out how we would bridge this gap and at the time, I had no clue that the whole impedance mismatch was such a real issue. (My google skills weren't up to snuff I suppose plus I was only 19 years old). Anyways... time goes by and I read more and more MSDN articles (woops!) who preach recordsets with OOP nowhere to be seen. It did not make sense to have this "Customer" class that would just have methods such as "GetAll" and "GetByLastName"... I thought a Customer would have attributes such as FirstName LastName etc... where was the OOP

NHibernate was my first eye opening moment... all of the sudden, I could code with real objects and have them persisted transparently. The next version of our application used NHibernate exclusively (although reporting bypassed it for the most part) and worked very, very well. There are parts of the application that aren't as OOP as I want, but the customers are completely satisfied so I would call it a success.

Well here we are for round 3. The application has to move from the realm of the desktop to the web. There are enough new requirements to justify at least a major rewrite (if not complete rewrite). In the time between finishing/maintaining version 2 and now, I have become a huge proponent of test driven development (TDD) and the "simplest solution possible". I am also learning more and more about domain driven design, etc. but it seems the more I learn, the more I feel I am doing wrong.

I think a lot of developers feel like there is some mystical object heaven when you finally realize all the mistakes you've been making and your applications will all of the sudden become object oriented. I can't speak for anyone else, but I'm stating that I do not feel this place exists. There are fundamental problems that all application have to solve that aren't as simple as just applying this pattern or that. Your code will get dirty, it will have pieces that touch the database directly (e.g. reporting and bulk updates/deletes) there are going to be times when you have to touch the ADO.NET namespace, when you have to work with DataSets (ICK!). This is inevitable.

As much as the object bigots would love it, you can't bottle everything up into an object. The mismatch still exists. Today is Friday and I'm having a cocktail while I write this entry. I've been thinking a LOT about my current development cycle and I am trying to refactor it! I think any developer worth a damn has to constantly strive for improvement. I am one of those developers that (unfortunately) always thinks about the big picture. This can be a good thing and a bad thing.

The good part is that you see the big picture and are able to make smart decisions about architecture (usually). The bad part is feature creep. You "know" that you are going to need some feature. Instead of focusing on the task at hand (the current use case) you constantly have big visions of the overall "architecture". Words like "framework" start popping into your head, you think about how you can abstract the current issue to solve so many other problems... you start having visions of "God" frameworks where everything can be abstracted to a Message class, I mean afterall, isn't everything in computer programming just a Message with a Response... wait... Response is really just a Message so we can do away with Response class and just have Messages and targets. This is starting to sound a lot like Smalltalk.

I guess what I'm getting at is that THERE IS NO SILVER BULLET. Your clients don't care about your architecture outside of what business problem it solves. If you are using datasets, objects, xml, json, csv, or a custom protocol (because you know you can get better performance) they don't care. What they see are a bunch of text fields on the screen that say First Name, Last Name, Address, Phone Number, and Salary. They fill them in and click Submit. They expect to be returned to a list of all the people in their database with one new entry. Whether you are using ADO.NET to save that record, NHibernate, or ODBC because ADO.NET is yet another useless layer to slow things down... they DON'T CARE. If the backend is PHP, ASP.NET, RAILS, or CGI - they also don't care. What they do care about is features and turnaround time on new features.

And this is where OOP and all these other ideas can help. Because sure, in a finite world, the application should be implemented in the fastest way possible. But how many applications are stagnant entities... almost 0. The users will want new features... how are you going to implement those? Well let's see what the major requirements are for a simple change... say we now need to store a Social Security Number field on clients. This is the sort of change we see in our application all the time and we've got a pretty good way of dealing with it. This being a Windows application with an SQL Server backend, here is how we cope with change.

Problem: Field needs added

1. Column needs to be added to schema

2. Property needs to be added to object (if you use classes like we do) e.g. Customer.SocialSecurityNumber

3. User interface element needs added on at least one screen to modify SSN (most likely more to display in grids etc.)

How do we handle it currently?

1. We have a schema script embedded in our app where we add the SQL to add the column (scripts are run at startup to update schema)

2. Add property to class

3. Add property element to NHibernate mapping

3. Add textbox to windows forms (and columns to listviews etc.)

4. Code to link to backend object for saving

I am able to do this in roughly 5-10 minutes for a single field being added, which isn't that bad. The next version we hope to be able to do this IMMEDIATELY. Single change to class by adding a property and perhaps some GUI code. Anyways - I've gone on a tangent and I've gotta roll. Peace out people.