Garbage Collector

Ran into a scenario this past week with the GC.

Take this example:

   1: public void Method1()

   2: {

   3:     object o = new object();

   4:     // Do Some work WITH o;

   5:  

   6:     // Do Some work WITHOUT o;

   7:     o = null;

   8: }

   9:  

  10: public void Method2()

  11: {

  12:     object o = new object();

  13:     // Do Some work WITH o;

  14:  

  15:     // Do Some work WITHOUT o;

  16: }

With method is more efficient?

At first glance you would say Method1 since it “cleans up” its variables.  Lets say o was actually a SqlConnection.  We would want to clean that up at the end of the scope right?

Maybe not, turns out the garbage collector in .NET is smarter than us.  In Method2, we don’t reference o after we are done using.  Since it isn’t ever used again the garbage collector will come along and clean it up for you before the method ends.  Pretty slick right?  Declare, use, forget… and I get the optimum effect for free.  Back to o being a SqlConnection, since o “may, if resources are needed or the os has some free time”, the connection will get cleaned up quickly.

Now, for the rub…

I was a good little developer and made sure the cleanup of my RootDisposable cleaned up its ChildDisposable when it was cleaned up.

   1: internal class RootDisposable

   2:     : IDisposable

   3: {

   4:     protected ChildDisposable MyChild { get; private set; }

   5:  

   6:     public ChildDisposable GetMyChild()

   7:     {

   8:         if(MyChild == null)

   9:             MyChild = new ChildDisposable();

  10:  

  11:         return MyChild;

  12:     }

  13:  

  14:     #region IDisposable Members

  15:  

  16:     protected void Dispose(bool disposing)

  17:     {

  18:         if (MyChild != null)

  19:         {

  20:             MyChild.Dispose();

  21:             MyChild = null;

  22:         }

  23:     }

  24:  

  25:     public void Dispose()

  26:     {

  27:         Dispose(true);

  28:         GC.SuppressFinalize(this);

  29:     }

  30:  

  31:     ~RootDisposable()

  32:     {

  33:         Dispose(false);

  34:     }

  35:  

  36:     #endregion

  37: }

I was also a good developer in that I implemented the Disposal pattern where the Finalizer calls Dispose(false), which will cause my child object to get cleaned up then also.

Now, for the cherry on the sundae, I built my app in Release mode for my customers, deployed it, and it broke for them.  WTF!?  (At this point blame QA, they should have tested the Release version instead of the debug! :D)

Check out the the trunk\Samples\AggressiveGarbageCollection sample in my codeplex site coderjoe.codeplex.com for sample that you can use to play around with this.  Just remember the code will only fail if you build it in Release mode :)

I snagged my GC collect code from example in GC.KeepAlive method in the msdn docs.

View – ModelView – Model+Controller… In that order!

So spinning along with Results-Driven.

Where to start your application design.  I’ve always started with the database.  Then used my tools to generate the model, apply my methods to the objects.  Build out the GUI, fix the bugs, and then release.  Smooth as chocolate silk pie :)

Maybe not, you end up spending forever trying to make your customer happy with the results.   My biggest annoyance is to have to tell my customer “It can’t work that way”.  I like to be the yes-man.

Starting with the GUI or the View avoids this situation.

From there you can start working on the ModelView.  The model view is doing two things for you at this point.  Giving you mocks to test your GUI, and also defining the “grain” of the application.

Understanding the “grain” of the application is important.  Too many times starting at the database level I created schema’s that were so fine grained they were almost unusable.  Models of 3rd, 4th and maybe even 5th level normalization.  Which in turn gave me super bloated business layers, and horrendous GUI’s.

Moving down the chain, the Model+Controller come into play next.  The model should just be data, the controller should be the methods to perform actions. 

So for a ModelView you might have an object like.

   1: public class ModelView

   2: {

   3:     public int Id { get; set; }

   4:     public string Name { get; set; }

   5:     public string Email { get; set; }

   6:     public bool IsNew { get; set; }

   7:  

   8:     public void New();

   9:     public void Load(int id);

  10:     public void Save();

  11: }

Based on the above ModelView, which is already wired up to the GUI, we can surmise that our Model+Controller needs at the very minimum.

   1: public class Model

   2: {

   3:     public int Id { get; set; }

   4:     public string Name { get; set; }

   5:     public string Email { get; set; }

   6: }

   7:  

   8: public class Controller

   9: {

  10:     public Model Get{int id);

  11:     public Model Create(Model model);

  12:     public Model Update(Model model);

  13: }

All that is left is to wire up our Model+Controller, as long as the user’s feedback was taken into consideration during the View-ModelView timeline, we should have a working app that everyone is happy with.  Plus 2 layers of flexibility, database changes can be worked out in the controller or service layer.  Gui changes can be worked out in the View-ModelView, and then flowed down through the rest of the system.  All is good in the world again.

The first time I took the GUI-First approach, was a Time-Entry system.  The module for the ERP system had everything we wanted, but the time entry system sucked.  Since I already had the tables the data had to fit into, I saw it as a challenge to let the users go wild with the gui.  I tried to put in all the nifty little short-cut items to help them enter their time as fast as possible.

The application was a phenomenal success.  The users loved the gui, and I mean loved it.  I was instantly promoted to Hero status.

Code can be found in trunk/Samples/View-ModelView-Model+Controller on my codeplex site coderjoe.codeplex.com.

Solution Organization

With our Proof of Concept demo with the customer completed, we are now ready to move on to the real solution.

Lets talk about source control. If you don’t have a favorite, find one. My preference right now is SVN. However use what you feel comfortable with. Make sure you understand it though. Source Control is your lifeblood. If you haven’t spent any time in the docs, or searching the web for best practices for your source control, do it, now! A good place to start, is Eric Sink’s Source Control HOWTO.

Now on to the “Solution”. It kills me that this gets overlooked so often. We are in a rush to get started, so open up VS, create project, and jump into writing code. We were supposed to get rid of those urges in our Proof of Concept…

The solution truly is your first public deliverable. If you work on a team, its the first thing the other developers will see. And your teammates are going to be the hardest group to appease.

Things to think about when setting up your solution.

1. Expect Change – I typically end up reworking my solution layout 1-3 times a year. Planning for change up front puts you in a position to allow you to try out new ideas midstream.
2. Don’t go overboard – a solution with 10 projects will typically always build faster than one with 40. Separating out each individual component into its own project may not be the best idea.
3. Avoid too much depth – We all want to be fast, the solution should be in a layout that walks me to what I need to work on quickly.
4. Avoid “Common” projects – Common projects turn into trash dumps that everything lands in. In my case I have a “Core”, core is a common project but it has rules. It can’t be dependent on any other project. This puts a restriction on what can be put into it.
5. Refactor happens, in both directions. Leave space in a “Core” library so you can move items up the hierarchy so they are usable across many sub-systems. I try not to put things into my core library initially. Some things are easier to develop on a micro-scale in the library that utilizes them. After the bugs are worked out refactor them into the Core.
6. Keep references local. You should never have any references or build steps that expect a full path (aka c:\windows\Microsoft.Net). Copy those referenced assemblies to an Externals directory tree, and check that into source control.
7. Solution layout should match the file system as closely as possible. Really the only reason it shouldn’t match is that you are trying out some layout tweaks to see how they feel before you go through the process of relocating files on the file system.

You can find a sample of my current layout at
coderjoe.codeplex.com –>Source Code->Browse-> trunk/Samples/SolutionOrganization

The top level is split out into zones.

• AssemblyInfo - common items shared across all projects. I typically put a constants file in here with all internal classes for my true constants.
• Core – This is my bottom layer refactor point. This is framework level code. Custom Linq extension methods, wrappers around streams and other utility classes or mini-systems like lightweight dependency injection systems.
• Data – These are my Data layer classes. One project for each database. Ideally these would contain mostly generated code using some other persistence framework.
• Databases – If you choose to store your your database schema scripts alongside you project, I’d put them here. Again 1 project per database.
• Externals – This is where I put all of my external references, my SharpZipLib assembly, the projects I download from codeplex or sourceforge. Anything that I didn’t produce as part of this project and expect to be mostly maintained outside of my project. Try to keep this structure and code as close to original as possible, makes it easier to manage merging in bug fixes to the projects as they change.
• Services – I typically like to wrap my database, and business logic together into a service of some sort. Now this doesn’t have to be WCF, or a WebService. Could just be an SOA style class. Based on n~tier design, you can consider this the Business Layer.
• Utilities, Websites, Applications – These are all of my final outputs. I don’t really have a pattern for this area yet. Utilities are typically console apps, so a listing of single projects is in the folder. Websites are very similiar to Utilities. Applications, meaning WinForms or WPF, typically have supporting libraries to go with them. so maybe 1 more level of subfolder below Applications with the Application name. I’m game for ideas here…

Now, at the low level, I’m sure you noticed the Globalization and Configuration projects. These 2 projects sit below Core in the project dependency hierarchy. I put this down at this level to serve as a gathering spot. I’ve worked on too many projects that developers get frustrated with these 2 items. They are either spread over the entire solution in little silo’s, or just flat never thought of. Either state is unusable, and therefore un-maintainable.

So when you get tagged with the need to localize your app, pass along the Globalization assembly to your localization team and be done with it. Or the more likely case of needing to tweak a setting on production, just pop open the config, add the setting and we are done. A little bit of forethought can go a long way to keeping things maintainable.

Proof of Concepts

So what is a Proof of Concept? A confidence builder for both you and your customer. Your customer will have the chance to see the fruits of your labor. Be able to offer feedback on what they expected vs. what you gave them. You now have real experience with the subject matter. You should be able to give relatively quick answers of "yeah we can do that", or "how about we do it this way". Also, it’s a place for us to ignore the realities of development and build something just for the sake of completing a task quickly. A place for us to learn the bounds of the technology. There are no rules in the Proof of Concept. Most important, its completely throwaway. Don't bother even checking this piece of crap into source control. I'm serious don't do it. Your next attempt at implementation will be 10 times better than anything you can steal from the proof. If we intended to keep the code, it would have been called a "Draft". Next time Solution Organization

Getting started.

Now, where to start... We need to figure out what the user wants in as little explanation as possible. The more you talk to the user the more chance they have to get a vision. Once they get that vision, it will be your responsibility to achieve it. If they start asking specifics or what you think, let them know you just want to get a “feel” for what they want. They can add details once you get the baseline in place. We don’t need/want to know every fringe case and how to handle it. Nobody knows the real business rules anyways. I don’t know how many times I’ve had an expert tell me it “HAS to work this way!”, then during the last week of testing (crazy scenarios are ignored until then), the final user tells the expert that rule was dropped years ago. Same thing with technology targets. I take our build server as an example. We purchased Team Foundation Server, plus Architect licenses for every developer we have. As a skunk works project I setup CruiseControl.Net to build and deploy our dev environment. My counterpart setup TFS, and the whole build process in there. Ran across 2 minor details that he didn’t feel like working out, that CC.NET could handle easily. And here we sit, with our SVN+CC.NET dev environment. If you build it, and it works, nobody will care about the details. So, you have survived the initial requirements gathering. Hopefully with no more than a little sketch of the interface you need to build. And pages of scribble to make it look like you were paying attention. Next time Proof of Concept.

Its all about the results.

Results... Forget about Agile, Waterfall, [ insert latest trendy methodology ]. In the end its all about results. My question, what is the "result"? Is it just the part that your customer wants. Is it the scalability of the architecture. How about enabling graceful change. Now that your app is prod the users hate it and want it to work the way you tried to tell them it should. Or maybe its high maintainability. Maybe you just don't know yet... My plan over the next few posts is to go over my methodogy for achieving the *best* result as fast as possible.