Scott Lilly – Agile .Net Developer

One of the important aspects of the framework is that it should be highly re-usable.  In order to make it re-usable, I’m building it with many small, independent (for the most part) projects.  Those small projects will eventually be used to make the more complex projects.

Think of this like cooking.  Let’s say that our framework provides potatoes to chefs.  Without the framework, each chef  needs to get their potatotoes, peel them, slice them up into the shape needed for the recipe, and cook them.  If we build something that provides us with peeled potatoes, that saves time for 95% of our recipes.  However, if we build something only provides peeled and diced potatoes, that’s not going to help the chef who needs sliced potatoes.  If our “cooking framework” only provided us with peeled, diced, roasted potatoes, it would be a great time-saver for 5% of the recipes, but useless for the remaining 95% of them.  So, I’m starting out the framework to do the simplest, most common tasks.

In the applications at work, one of the most common tasks is to get a list of jobs from the database.  I expect that most programs have their own code to access the database and get this list of jobs.  With all those different versions, we end up with several problems.

• - The code for each versions may not be optimized (the query being used, handling of disposable objects, caching, etc.)
• - If we ever need to change the database (or it’s structure), we need modify each program.
• - If we want to improve performance with caching, we end up with one cache per program (not as efficient as a common cache).
• - Each programmer had to spend time writing, testing, and debugging their version of the function.

So, this will be the first thing I’ll add to the framework.

I created two projects: ABCD.BusinessObjects and ABCD.Persistence (”ABCD” will be the fake acronym I use for our real division).

The ABCD.BusinessObjects project will be used in almost every project.  This contains classes like the Job object.  I’m building these classes using the Data Mapper design pattern.  I don’t want to use the Active Record design pattern, where the record contains methods to create, read, update, and delete that object from the database.  All the database access code is going into the ABCD.Persistence project.  My feeling is that the Active Record pattern produces objects that don’t pass the “Single Responsibility” aspect of the SOLID principles.  These classes are currently fairly simple, containing mostly get/sets for the properies.

All the business objects inherit from a BaseBusinessObject class.  The only thing in that class is a getter for a virtual boolean property named “IsValid”.  It currently returns “true” in the base class.  By overriding this method in the derived classes, we can have all the validation rules stored along with the class.  Even though the base class doesn’t do anything yet, I put it in place to provide me with a point of flexibility in the code.  If we need to add in something that applies to all classes later on, we already have a place to put it.  If we don’t, even though this class violates the YAGNI principle, it isn’t a burden on us for performance or developer understanding.

The only thing in this project (other than more business objects) is a class to hold enums used by the business objects.  It’s a public static class named ABCDEnums.  I’m a fan of using enums for the datatypes of properties.  I’ve run into too many situations where a boolean property suddenly needs to store a third value.  I believe that FxCop (Microsoft’s code quality tool) even mentions that you should have an “Unknown” or other default value available with each enum.  The reason I’ve added this enums class is because it makes the enums very visible through Intellisense.  If I can’t remember the exact enum name, all I have to do is type “ABCDEnums.” and they will all appear.  That’s also the reason why I’m naming all the namespaces with ABCD.whatever.  When I’m adding in my “using” statements at the top of the class, I quickly get to the point where Intellisense starts showing the available namespaces.  That’s much easier than trying to remember the exact spelling and upper-casing of some long namespace like “BusinessObjectsForEAISystem”.  Although, a tool like ReSharper would be even better (IIRC how it worked during the 30-day trial of it).

My next post will be on the ABCD.Persistence project.  I’ve been going back and forth on a couple of ways of building it, and I expect I’ll have that finalized soon.

There used to be a television commercial for some candy that had chocolate and peanut butter.  In it, there would be one person walking around with an open jar of peanut butter and another walking around with a chocolate bar.  They would bump into each other and the chocolate would end up in the peanut butter.  The peanut butter owner would exclaim, “You got your chocolate in my peanut butter!”  While the chocolate bar owner would shout, “You got your peanut butter on my chocolate!”  They’d both try this new concoction, declare it an amazing snack, and all of us viewing would go out to buy the candy.

What does all this have to do with programming?  While thinking about how to develop a good framework for the suite of apps I work with, I’ve been looking at what I’ve seen that works and what doesn’t work.  One thing that I see a lot of is procedural code written in object-oriented languages.  We’ve all seen (and probably created) classes with a method that is hundreds, if not thousands, of lines long.  You got you procedure in my object!  But I think the opposite problem can also occur.  When working towards an “ideal” application, you can try forcing procedural processes into objects, handling them with massive event raising or forcing them into place with an implementation of the Chain of Responsibility pattern.  You got your object in my procedure!

One of my thoughts when creating this framework is to have objects (Customers, Jobs, etc.) represented by objects, and have processes handled in procedural methods.  I’ll still be following the SOLID principles, especially Single Responsibility and Dependency Inversion.  However, I won’t be forcing things to use styles that don’t seem to be appropriate.  My next post will go into some detail of how (and why) I’ve set up the projects for the framework.

BTW, as I started writing this, a friend of mine sent me an e-mail with a link to a funny history of computer languages, complete with a reference to the chocolate/peanut butter commercial.  Check out this Brief, Incomplete, and Mostly Wrong History of Programming Languages for a laugh.

It’s been quite a while since I last posted, but I’ve been keeping extremely busy.  Since my last post, I started a new job, in a new industry, writing a [mostly] new to me type of application. Add in moving and all the other things that life entails, and it’s been hectic.  But sanity is slowly starting to return.

The job I’m at now is full-time, heads-down development.  However, it’s Windows Forms applications instead of the web services, Windows services, and back-end business processing that I’ve been doing for most of the last several years.  I finally get to spend my days writing programs that users can actually see!  After years of staring at XML all day, it’s cool to work on something that shows graphs of data … in different colors, even.  Without going into more detail than my boss probably wants me to, the programming team I’m working on produces a suite of dozens of individual applications that all go against the same database.  “My” application parses files in numerous formats, displaying the data in graphs and reports.  It also needs to send the parsed data to the database and be able to output it in a couple of other formats.

My current focus (and what I’ll be posting about) is building a high-performance framework that can be used by all the applications in our suite.  I’m not building the framework from an ivory tower.  Instead, I’m writing a stripped-down version of the application I work on, and building it in a way that will make it highly re-usable and improve the performance.  At work, there’s a definite C++ bias for anything that needs to be high-performance, but I think I can do just as well in plain-old C# (plus avoid the overhead of COM interop or P/Invoke).  So, whenever I build part of the framework, I write a mini-load test app to see how well it works.  I’ll eventually start doing some more serious profiling of the throughput, CPU load, and memory usage.

Another thing on my research list is F#.  In order to get a further performance boost, I’ll also be looking at using F# to create code to take advantage of multi-core processors.  I haven’t even written a Hello World program in F# yet, but what I’ve been reading about it has impacted how I’m writing code.  I’m focusing more on separating my “state” from my “process”.  I’ve noticed that I’m starting to write more static methods, which isn’t helping with testability.