The Static Spider Web Pattern

“I’m picking up your sarcasm.”

“Well, I should hope so, because I’m laying it on pretty thick.”

–Tommy Boy

While the developer lexicon is loaded up with more patterns than we can possibly ever learn, I just wanted to introduce one of the more important patterns that I think exists out there in software development. I call it the “Static Spider Web” pattern. The main driver behind this pattern is that object instantiation, allocation, and deallocation impose far too much overhead in modern programming language runtimes. Since we aren’t in direct control of memory management, and since garbage collectors on systems with large amounts of memory can cause huge latency overheads, we need to find some way to minimize, at all costs, the number of objects that we allocate.

First, we are going to have to just accept the fact that we will have to create a few objects. I mean, our application data needs to go somewhere, right? I’d advocate for passing the data around as parameters, but that would get old pretty quick with all of that typing. Besides, that is what objects were invented for, to be stateless data containers.

Let’s Get Started

The first thing you will want to do is create your business object:

public class Person
{
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public DateTime BirthDate { get; set; }
}

Now that we have our business object, we are going to have to do something with it. So I am going to create a class which will allow me to perform a save operation on my business object:

public static class PersonManager
{
  public static bool SavePerson(Person person)
  {
    
  }
}

I like to use the term “Manager” since it is very generic. That allows me to shove pretty much whatever I want in there. This keeps me from having to create too many classes. I like being efficient.

So now that I have a class which will allow me to save my Person class, I just need to save it to the database. To do that, I create another class which will allow me to save it off. I know I said I like to keep the number of classes to a minimum, but in this case it is good to keep all of your data access in one place:

public static class DataLayer
{
  public static bool SavePerson(Person person)
  {
    // save person to database
  }
}

I call this class “DataLayer” so that I can avoid having to create a different one for each of my business objects. This way I can just keep putting more and more methods in there. Eventually it gets pretty big, but when that happens I just wrap each section in regions so that it looks really small:

How cool is that? Almost 6000 lines, but you can’t even tell! This is what I call “code hiding”. It should only be used by super expert coders.

Making Things More Clear

I think you are already starting to really get a good idea of where I am going with this pattern. But I’ve often felt that a diagram always helps get the point across:

So, as you can see, we have some objects that get passed down at the top, and then they get fed into this very simple and efficient web of static methods. These static methods will then call each other, call out to third party libraries, call out to helper classes, or call into the data layer. Occasionally I like to call out to web services for when I am doing service oriented architectures. Or if things get really crazy, I’ll put some XML serialization in between the layers. Then it would look like this:

You may think that this might get out of hand, but by keeping everything as static methods in a bunch of different classes it allows for maximum code reuse since anything can call out to anything else. You may think that this breaks concepts such as encapsulation, but we are keeping all of our data in classes, so I don’t think that we really need to worry about that.

Testing

With the Static Spider Web pattern testing is really easy. You just have to create your objects and pass them into the static methods in the Manager Layer. Then you can just check to see if what you expected to happen actually happened! How simple is that? Of course you are going to want to make sure that you have a full test environment setup before you do this. You’ll also want to make sure that you have different types of config for production and for testing so that you can hit different local databases. You’ll probably also want different databases for your unit tests, and reset scripts to get your data back the way you want it. Oh, and you probably also want settings so that you can write to local directories instead of network paths. You know, all of the stuff that is different from your local and production environments. But creating settings for those and then wrapping all of the calls to it is only a few lines of code. Well, a few lines of code repeated a few thousand times, but still, it is really simple code to write.

If you happen to be calling out to web services, you’ll probably want to also setup alternate test web services that you can call. If you don’t have test web services, then you’ll probably need to put in code around every call to them that checks if you are running in “debug” mode. As far as third party code goes, you might need to put checks around calls out to those as well. But other than that, testing should be a breeze.

Summary

Overall I think that the Static Spider Web pattern isn’t for every application, just most of them. It is a very simple pattern that doesn’t really take much effort or forethought to implement. Once you do implement it, you’ll find that your development will go very quickly and you’ll be cranking out feature after feature in no time.