When we write automated tests, we want to do it in the simplest way possible while achieving the highest level of quality for the time we invest in our tests. Unfortunately, this is easier said than done.

Writing tests can be hard. It’s hard figuring out what kinds of automated tests to write. We can write unit tests, integration tests, functional/acceptance tests, performance tests, or just do manual testing. We have to decide if developers are writing tests or if QA people are doing it (or both). It’s really complicated!

Let’s look at some ways that people sometimes tackle the testing problem and then discuss some different ways we can approach it.

The black box

On some projects, the team is testing a big black box. Usually this is where QA people are doing all the testing and developers aren’t writing automated tests. If you read my blog at all you know that I do not like this approach (unless time to market is really that important) because it leads to lots of bugs and makes refactoring anything really scary. In this scenario, QA testers typically only control the inputs and outputs into the black box (which is usually a user interface of some kind). This leads to problems like having to jump through a bunch of hoops just to test something that’s farther down the line of some complicated workflow.

Tiny slices

If you’re a fan of test-driven development, you will write a lot of unit tests. In this case, you’re slicing your application up into very tiny, testable units (like at a class level) and mocking and stubbing the dependencies of each class. This gives you faster, less brittle tests. You still probably have QA people testing the black box as well, so now we’re using two different approaches, with is good.

I’m not satisfied

While each of the previous two approaches have their positives, they both have their negatives. I’ve already talked about the negatives of all manual QA black box testing, so I won’t go into that again (although I’m always up for a good rant). But writing lots of unit tests has its problems as well. For example:

• Tests with lots of mocks and stubs, and failing tests that fail because someone refactored a class any now my stubs and mocks are all hosed. You know the feeling.
• Testing an individual class or method is great, but my tests aren’t always testing something that has business value on its own.

No limits

You own your application. Your application does not own you (at least it shouldn’t). We also own the testing of our application and should be able to test it in any way that we can think of. The goal is high quality, low cost of maintaining the test suite, and speed to market. How can we best achieve this goal? (And don’t just give me the first textbook answer that pops in your head.)

There is no one-size-fits-all method for testing applications, and there isn’t even one single best way to test a single application. So what if we used many different approaches and broke our system up into chunks so that we can use each testing method to its fullest potential?

In this case, I’m dividing up my application into separate modules, each with its own purpose, function, and business value. Some may have a user interface component and other might just do some task behind the scenes. I can decide how to best test each module individually. Maybe some modules are done with all black-box acceptance testing, and other modules are done with lots of unit tests. Even within the black-box modules, I might still write unit tests. Of course, I’m still going to have some end-to-end tests (manual and/or automated) that test the whole system working together, but I don’t have to test the majority of the functionality this way.

My favorite kinds of tests are ones that test a system working together because I can specify the inputs and outputs and I don’t have to deal with tons of stubs and mocks. Now if you try to test the whole application end to end this way, it can be a bit cumbersome. But if you have a smaller module that you can test end-to-end, now you can have clean, readable, well-defined tests that don’t have tons of mocks, and the tests define some business function that the module needs to perform. My module might still work independent from the UI or the database, so I might still be able to stub those out and have fast tests. This feels like the kinds of tests I’ve always wanted – tests that test a module end-to-end but are able to run fast because I can still isolate dependencies.

Hey, look, it turns out that modular applications is a good idea in general! It’s way easier to deal with lots of smaller applications that work together than dealing with one monolithic application. Those of you with large solution files and long compilation time (I’m raising my hand) know the pain of dealing with large applications.

The emerging blob

We like to talk about “emergent design” and that we can write tests first and let that drive the design of your code. That is true, but your codebase will evolve into a monolithic (albeit well-tested) blob of an application that assimilates all code into it’s large collective.

The only way you’re going to have a modular application is if you draw the lines in the sand up front. This can be really hard to do when you have a newer application and you don’t have a ton of insight to tell you how to keep things separate. Compounding the confusion is the fact that you might have a single database for the application as a whole, which I think is fine. You can multiple modules that use the same database, even the same tables. Sure, it would be better if you can keep the tables in separate databases, but sometimes that’s not possible or realistic.

You might start out with certain modules and then realize that you created a separation that is too painful to maintain. That’s OK, it’s much easier to combine two modules than it is it try and separate things into modules after the fact!

Once you’ve defined your modules, now you can decide how to test them (QA and devs should work together on this!).

This feels better

• Cleaner tests with fewer mocks that test mini-systems that provide some function or business value
• More modularity means I can change code without potentially breaking as many things
• Smaller solution files!

I really like how this sounds.

We all love the DRY principle (Don’t Repeat Yourself). It really is a good idea, we don’t want to have two places in the code that do the same thing, and we want good object-oriented design. But even DRY can go too far.

Recently I’ve run into some cases where DRY decreases the readability of the code. I had some simple classes to write that do some relatively simple calculations, and the business rules are fairly similar to some other classes that exist, but with a few differences. I started down the path of making one class that can handle all situations, with hooks for modifying the behavior of the class (either virtual methods or configuration settings somewhere else).

This is all well and good until you realize that now you’ve taken something simple and turned it into something really complicated that even you have a hard time understanding anymore.

DRY is great, but I lost sight of why DRY is good. DRY is good because it makes code more maintainable, more consistent, and easier to understand and add new functionality. But as soon as DRY stops providing those benefits, maybe it’s time to keep things simple and just write readable code that makes sense, even if it means you have a little bit of duplication.

Software applications typically deal with two things — data and behaviors. The behaviors of the application use and modify the data and represent the business processes that we model using things like code and databases.

We all know that data is important. Most people think of the data as being very important, and often applications will have a very data-centric feel to them. The app may have some representation of the schema (e.g. using an ORM, creating business objects that mostly have the same properties as a database table). This is all well and good. But many applications struggle because they don’t stress the importance of the behaviors when writing the code.

The Wild West Data Access Strategy

I believe that the following simple rule should apply:

No data should be modified unless some behavior is requiring you to modify it.

If we don’t have some business reason to change data, then we shouldn’t be doing it. I’ll explain this by first showing you how not to do it.

Take ORMs for example. I like ORMs. There’s no reason to write ADO.NET code anymore, there is a much easier way to do data access.

The problem with ORMs is that you can load up any object from the database, change any properties of the object that you want, and then save it. This is very convenient, but too often people don’t make it clear why they are changing the data. You see this when people have huge “manager” classes (e.g. OrderManager) that contains a whole bunch of methods that load, save, and modify data. The problem is that when you have to modify code in those applications, it’s hard to do so because you don’t know what other things might be using that code and it’s not always clear why the code was written in the first place. Sure, maybe my IDE will tell me what methods call my method, but it might not tell me what behavior required that code to be written.

This can get even worse. I’ve used NHibernate on many projects and I’ve gotten to know it pretty well, but NHibernate has this concept of FlushMode. In NHibernate you create a “session” (which is different from the “session” in-memory cache in web frameworks). Within a session, you can load up objects from the database and NHibernate will keep track of what objects are dirty. The default FlushMode in NHibernate is Auto, which means that every time you do anything that accesses the database (be it a call to save or even a query), it will save all dirty objects to the database. This leads to incredibly brittle code. I don’t ever want my data to be modified unless I do it for a very specific reason, and I certainly don’t want data updated when I do a query! (You’re better off with FlushMode.Never, which means that you have to explicitly tell NHibernate to save dirty objects.)

Note: It sounds like I’m ORM bashing here, but I typically like to stay away from stored procs unless I’m doing something that requires SQL (like a complicated search query). I really don’t like any business logic in stored procs because now my application is very tightly coupled with the database. It’s much easier to manage and test business logic in the application code. If you don’t like the heavy handed ORMs like NHibernate and Entity Framework, try “micro-ORMs” like Simple.Data.

A Better Way

How you do your data access actually isn’t the issue here. What I really want to talk about is how to structure your application code to emphasize the behaviors that your applications are doing, which usually involves some data access. Everything needs to driven by some business process that needs to be done. For me, this usually starts with an acceptance test, which may or may not be automated (in my code, it’s usually automated).

Scenario: User deposits money in an account
   Given a bank account
   When the user makes a deposit
   Then the balance should increase by the amount of the deposit

Then I have some class that is going to do this specific task.

public class DepositCommand
{
    public IRepository AccountRepository { get; set; }

    public void Execute(IDepositModel model)
    {
        model.Account.Deposit(model.DepositAmount);
        AccountRepository.Save(model.Account);
    }
}

On my current project, we like having lots of little command classes like this. Each class has a very specific purpose that can be linked back to a business requirement (because we write our requirements using the same command names as the code). We sometimes string a bunch of these commands into a “workflow”, which is nothing more than a series of commands run to complete a larger task.

Back in the day, I would just have big classes like “AccountManager” that would have a bunch of methods on it. When I was on a Ruby on Rails project, we didn’t have to use dependency injection (because Ruby is awesome like that), so our business model objects contained lots of methods that would do things, but these model objects could get really really big. In either situation, I prefer creating smaller command or query classes that either modify something or do some query.

All I’m really doing is rearranging around my code, so what’s the big deal? It’s much cleaner with command classes in my opinion because that class has one specific task. Those command classes often have private methods that help do the work. If I had a huge AccountManager class or a big model object in Rails, it’s not always clear which private methods go with which public methods, or what might be affected if I change them. In a small command class, if I change something in a private method, I know that it can’t affect anything outside of that class. Not only that, everything in my code and my tests is pointing back to some business requirement that is telling me to do something.

What I’ve realized is that the when I place more emphasize on the behaviors that I’m trying to implement in my code, the more I change my code to reflect those behaviors, even down to how I structure my code. By structuring my code in this way, I’m constantly reminded of the behaviors that I’m trying to implement and the reasons why I’m writing the application in the first place.

Several people took issue with my last post about Ruby on Rails saying that my example violates the Single Responsibility Principle. Here’s where I stand on this.

The SOLID principles are principles, not hard and fast laws of software development. When applying the SOLID principles, common sense should rule. There are times when violating the textbook definition of the principles is OK (regardless of what language you are using). The ultimate goal of all design principles should be reducing the cost of change. Reducing the cost of change comes in many forms:

• Being able to get things done faster because you have to write less code
• Being able to get things done faster because it’s easier to figure out code and what you need to change
• Being able to get things done faster because code is wrapped in tests so you can change it and not worry about breaking things
• Being able to get things done faster because you have automated tests which decrease the amount of manual testing that you or your QA team needs to do
• Being able to get things done safer by having abstraction layers in place so that changing code in one place doesn’t break something else
• Having well defined requirements so that you don’t waste time on rework
• Having business sponsors available to answer questions quickly
• Many more reasons that I’m not thinking of

With this in mind, all of my design decisions, including how I apply the SOLID principles, need to reduce the cost of change.

Also, keep in mind that the SOLID principles were written with static-typed languages in mind (C++, Java, .NET). While a lot of the same principles apply in dynamic languages, you can’t assume that everything is the same. In fact, the “I” and “D” of the SOLID principles arguably don’t apply to dynamic languages at all.

Several people said that my Ruby class violated SRP because it mixed class behavior, database mapping, and validation all in one class. Again, this is where I would take issue with your application of SRP. Here is the Ruby class in question:

class User < ActiveRecord::Base
  belongs_to :user_status
  has_many :roles, :through => :user_roles
  validates_length_of :name, :maximum => 100
  named_scope :active, :conditions => ["user_status.id = ?", UserStatus::ACTIVE]
end

On my last .NET project, I had domain model classes like this:

public class User : Entity
{
    public virtual long Id { get; set; }
    [Required("Name"), Length(50)]
    public virtual string Name { get; set; }
    public virtual IList UserRoles { get; set; }

    public virtual bool IsInRole(string role)
    {
        // code here
    }
}

I was using Fluent NHibernate as my ORM on this project, so I had a database table that looked like this object. So in this case, I have class behavior (IsInRole method), validation (the attributes on the Name property), and implied database mapping (using Fluent NHibernate conventions). How is this any different than my Ruby class?

Some people might argue that the textbook definition of SRP would say that I shouldn’t put validation attributes on properties like that. What is your other alternative? Write a line of custom code in an IsValid method or in another validator class, I assume. Is that reducing the cost of change? If I write custom code, I have to write a test for it. If I write boilerplate stuff like “[Required(“Name”)]” or “validates_presence_of :name”, that is so simple that I’m not going to write a test for it because I don’t think I gain anything from doing so. If I can add a whole bunch of behavior in just one line of code, then potentially violating the textbook definition of SRP is OK with me because it’s way easier to do it that way and it just makes sense.

Back to my Ruby class. My class knows how to load, save, and delete itself. In .NET, I would say this is a bad thing. First of all, I wouldn’t be able to stub out the database in a test (which I can in Ruby because I can stub out anything). Second, if you have multiple entities that do things a certain way (e.g. multiple entities that need to be cached when loading, saving, or deleting them), you would have no easy way to do that without duplicating some code (in Ruby, I can create a module and include it in a class, and in that way I could override a method like “save”). Third, I would have a direct dependence on the database, which violates the Dependency Inversion Principle (which doesn’t apply in Ruby, because all I’m depending on is some class out there with a method with a certain name, as opposed to .NET where I’m depending on a method in a class in an assembly in a .dll with a specific version). So as you can see, your domain model takes on a much different shape in Ruby vs. .NET. Both ways have their pluses and minuses, but each way is the best way for the language that you’re using.

There is one area where I see an interesting clash of Ruby and SRP. Because I don’t have to use dependency injection and because I can stub out any method in a test, it makes sense to put all methods relating to an entity object into the entity class itself. This just makes sense, and TDD would lead you in that direction. Doing this will lead you into having some really big domain model classes though.

Would this violate the textbook definition of SRP? I would say yes. You run into some of the issues that you have with big classes (harder to read). In .NET, we would argue that we should move a lot of this behavior into domain service classes, which would be smaller and easier to use in other classes (by taking the interface into the constructor of the class that was going to use it). In .NET, you have to pull things out of the entity object in order to be able to stub it out in a test, so at that point you might as well go the rest of the way and make small classes. But if you had the flexibility of being able to stub out anything in a test and you had Ruby-style mixins in .NET, would you really do it this way? One could argue that the .NET way of doing things in domain services is an example of Martin Fowler’s anemic domain model anti-pattern.

In both languages, you are making a tradeoff. In .NET, we are saying that testability is more important that potentially having an anemic domain model and having model behavior scattered around in domain services. In Ruby, we are saying that we would rather have all of the behavior in the entity class itself because it makes sense to have it there (we don’t have to worry about testability because everything is testable), even though we could end up with some big classes. Neither way is necessarily wrong, it just depends on the language you’re working in. In some cases, the .NET and Ruby communities have generally agreed on their own “best practices” and ways of doing things, and that’s just how people do things in those languages, often because the languages and frameworks make it easier to do it that way.

In summary, it depends, and use common sense. Remember what your goal is — to deliver working software. Your architecture is not the deliverable, and it’s not what makes money for the business. Flexibility, design patterns, abstraction layers, and the like often come at varying levels of cost. It’s up to you decide if it’s worth it in your situation.

UPDATE: This post has been updated to account for the StructureMap API changes that happened sometime around StructureMap 2.5.4.

We all know that StructureMap is great for implementing dependency injection in your application, making your app more testable, and all that. But StructureMap can do so much more than that. StructureMap can help you create pluggable project architectures that can allow you easily modify how your application works in certain situations with minimal to no configuration.

Let me explain. Most people have some kind of layered setup in their projects. The basic architecture is 3 tiers — a UI layer, a business layer, and a data access layer.

Entity objects are going to flow through these layers. You will load, save, and delete entities. And in most cases, the way that you load, save, and delete these entities will be the same — but not always the same.

What we want to do is write code to handle the normal entities and write it just once. If we need to modify how things are done for a certain entity, then we’ll write code for that. By doing it this way, we should have little or no code duplication.

The diagram on the right shows our project structure. You will notice that we have some generic interfaces defined in the business layer and data access layer. That classes that implement these interfaces will perform the specified actions using an entity (the generic parameter T in each interface).

Here’s an example. The IRepository<T> interface contains methods that will talk to the database. I will create a concrete class called Repository<T> that implements the standard method of talking to the database. This is how most of our entities will be loaded, saved, and deleted.

public interface IRepository where T : class
{
    T Get(long id);
    IList GetAll();
    void Save(T target);
    void Delete(T target);
}

public class Repository : IRepository where T : class
{
    public T Get(long id)
    {
        // do stuff here
    }

    public IList GetAll()
    {
        // do stuff here
    }

    public void Save(T target)
    {
        // do stuff here
    }

    public void Delete(T target)
    {
        // do stuff here
    }
}

Let’s say that I have a Customer entity that is persisted to a different database than the rest of the application. I now have a special case where I need to write custom repository code for a Customer. So I’ll make a class called CustomerRepository and have it implement IRepository<Customer>.

public class CustomerRepository : IRepository
{
    public Customer Get(long id)
    {
        // do custom stuff here
    }

    public IList GetAll()
    {
        // do custom stuff here
    }

    public void Save(Customer target)
    {
        // do custom stuff here
    }

    public void Delete(Customer target)
    {
        // do custom stuff here
    }
}

Here’s where StructureMap comes in. I’m going to configure StructureMap so that I can ask for IRepository<T> for some entity T and it will give me back the correct concrete class. This means:

IRepository<Product> maps to Repository<Product>
IRepository<Order> maps to Repository<Order>
IRepository<WhateverOtherEntity> maps to Repository<WhateverOtherEntity>
IRepository<Customer> maps to CustomerRepository (because CustomerRepository implements IRepository<Customer>)

Look at how easy this is going to be! I’m not going to have to do any extra configuration or wiring up to change how Customer entities are persisted. I’m not going to write any extra plumbing code, I’m just going to create the CustomerRepository class and implement an interface, and now my app deals with Customer objects differently.

Obviously there is some fancy plumbing going on behind the scenes, so let’s see how we set this up.

It’s really not that hard, actually, because most of the hard work is done by StructureMap. We just have to do some simple configuration.

Here’s how we initialize StructureMap:

public class StandardStructureMapConfiguration
{
    public void Configure()
    {
        ObjectFactory.Initialize(x =>
        {
            x.Scan(scan =>
            {
                // Automatically maps interface IXyz to class Xyz
                scan.WithDefaultConventions();
                scan.ConnectImplementationsToTypesClosing(typeof(IRepository<>));
                scan.ConnectImplementationsToTypesClosing(typeof(IGetObjectService<>));
                scan.ConnectImplementationsToTypesClosing(typeof(ISaveObjectService<>));
                scan.ConnectImplementationsToTypesClosing(typeof(IDeleteObjectService<>));

                scan.Assembly(GetType().Assembly);
            });

            x.For(typeof(IRepository<>)).Use(typeof(Repository<>));
            x.For(typeof(IGetObjectService<>)).Use(typeof(GetObjectService<>));
            x.For(typeof(ISaveObjectService<>)).Use(typeof(SaveObjectService<>));
            x.For(typeof(IDeleteObjectService<>)).Use(typeof(DeleteObjectService<>));
        });
    }
}

Let’s break this down and go over what I’m doing here.

scan.WithDefaultConventions();

This tells StructureMap to automatically map an interface IXyz to class Xyz. Most of the time, the names of your interfaces are just the concrete class with an “I” slapped on the front. This only applies to non-generic classes, so this isn’t necessarily helping us with our IRepository<T> example, but I do it on every project, so I thought I’d throw it in.

scan.ConnectImplementationsToTypesClosing(typeof(IRepository<>));
scan.ConnectImplementationsToTypesClosing(typeof(IGetObjectService<>));
scan.ConnectImplementationsToTypesClosing(typeof(ISaveObjectService<>));
scan.ConnectImplementationsToTypesClosing(typeof(IDeleteObjectService<>));

We don’t just want to use the default conventions, we want to tell StructureMap to map concrete classes that implement generic interfaces. Basically all we’re doing here is telling StructureMap that if I have a custom concrete class that implements one of these generic interfaces, we want to automatically wire those up.

scan.AssemblyContainingType(GetType().Assembly);

We want StructureMap to look inside the specified assembly and apply the conventions to the types in this assembly. You can also do scan.AssemblyContainingType<T>.

x.For(typeof(IRepository<>)).Use(typeof(Repository<>));
x.For(typeof(IGetObjectService<>)).Use(typeof(GetObjectService<>));
x.For(typeof(ISaveObjectService<>)).Use(typeof(SaveObjectService<>));
x.For(typeof(IDeleteObjectService<>)).Use(typeof(DeleteObjectService<>));

Here we are wiring up the generic interfaces to the default concrete implementations of each interface. This is for the 95% of the time when we’re using the normal way of doing these things.

StructureMap needs to be initialized whenever your application starts (Program.cs for WinForms, App.xaml.cs for WPF, Global.asax Application_Start() for web apps). So in this case, I would new up an instance of the StandardStructureMapConfiguration class that I created here and call the Configure() method, which would do all of the ObjectFactory.Initialize() stuff.

I created a small sample project with this code. This is really easy to implement and it makes development a lot easier by reduces the amount of tedious plumbing code that you need to write.

Someone asked me the other day if putting Load(), Save(), and Delete() methods in entity objects is a bad thing. While I tried my best to explain why I don’t put these methods on entities, I thought it was worthy of a blog post.

I am a .NET developer, so I’m going to answer the question with how I would do it in .NET. If you’re working in a dynamic language like Ruby, things are certainly different and you don’t have all of the limitations that you have in .NET. So what I’m about to say really only applies to the static-typed languages (.NET, Java, C++, etc.).

First of all, I am writing unit tests, which means that I’m using concepts like dependency injection. Someone who doesn’t write unit tests or use dependency injection might not see value in structuring their code the way I structure it. But the arguments here only partially have to do with testability.

Let’s say that I have these entities in my application — Product, State, Country, Customer, Order. In this list I have some things that change often (Customer, Order) and some things that won’t change often (Product, State, Country). So let’s say that I decide that I’m going to cache the entities that don’t change often.

Let’s think of this in terms of loading, saving, and deleting. When I load them, I’m going to check the cache first. When I save them, I’m going to save the object to the cache as well as the database. When I delete them, I’m going to remove them from the cache. I’m going to change how these types of entities are loaded, saved, and deleted.

Now let’s imagine that my entities had methods like Load(), Save(), and Delete(). I would have to implement the special cached loading, saving, and deleting in three places – Product, State, and Country (and whatever other cacheable entities that I have). Any time you have to copy and paste code you should start to wonder if something is wrong.

In this case, I might deduce that the way to solve the duplication would be to split out the code that loads, saves, and deletes cacheable entities into some other class that is outside of the entity class. These classes would be powerful because they aren’t just acting an individual entity type, they are acting on certain kinds of entities. Maybe you specify that an entity is cacheable by having it implement and interface or maybe you decorate it with an attribute.

Now when you have another cacheable entity, all you have to do is implement the right interface or put an attribute on the entity class and it will automatically work with the cache!

This is a good example of the difference between object-oriented code and procedural code. We want to do more object-oriented programming and less procedural programming because object-oriented code is more testable, flexible, and reusable.

There are also testability reasons for not putting Load(), Save(), and Delete() on entity objects. If you don’t understand dependency injection, you should go read about it first so that this makes more sense.

When using dependency injection, you take in dependent classes through the constructor, but you don’t do this with entity objects because entity objects do not have dependencies. Entity objects define what the model is, and other classes (“domain services”) define how the entities work together.

Earlier in the post I talked about how I would create a class that knows how to save cacheable entities. If I had a Save() method on my entity class, I would need to call this other class (a dependency) from my entity’s Save() method. But remember, entities don’t take in dependencies, and I don’t want to new up the class that does the saving because now I can’t mock that class in a unit test.

You might be reading this and it might not make a whole lot of sense, but that’s OK. This is much different from how some people have written code for a long time, and they don’t teach you this type of stuff in school. But it’s always a good idea to question why things are done certain ways and maybe you’ll learn something new that can really help you out.

In my last post, I mentioned that I think that hand rolled data access layers using stored procedures are a bad thing, and one of my co-workers asked me to elaborate.

The main reason that I don’t like hand rolled data access layers is that by writing your own DAL, you are basically reimplementing a solved problem. Think about all of the things you have worry about if you write your own DAL:

• Creating the CRUD stored procs
• Writing ADO.NET code to call the stored procs
• Figuring out which entities are dirty and need to be saved, and which properties have changed
• What relationships do you load when you load an entity from the database? How do you do lazy loading of relationships?
• Writing tests to test all of this custom code that you have to write

There are numerous object-relational mapping (ORM) tools out there which take care of all of this. NHibernate is my favorite (more specifically, Fluent NHibernate). NHibernate has been around for several years and is very mature. There are ORMs from Microsoft (LINQ to SQL, Entity Framework), and numerous other ORMs out there.

These ORMs have thousands of people using them, so they have been well tested and have proven over time to be very effective at what they do. Countless hours have gone into the development, design, and testing of these ORMs.

Think about what you are trying to do by writing your own hand rolled data access layer. Who are you to think that you can do a better job in a short amount of time than the people who developed these mature solutions over several years? Data access is a very complicated thing to try and implement, and some of the most painful code that I’ve ever had to deal with was found in someone’s hand rolled data access layer.

Here’s the thing — a large percentage of your data access is vanilla loading and saving of objects from the database. In these cases, performance is not a concern and you do not need any special queries in order to optimize the loading and saving of these objects.

For a very small percentage of your data access, performance may be a concern and you may need to use custom stored procedures. So in these cases, you can bypass the ORM and write your stored procedures and custom code in order to optimize the loading and saving of these specific objects.

If you use stored procedures and custom code, you have more control over things. This also comes with a cost (longer time to develop). If you are accepting this cost for cases where you don’t need to optimize the data access, I would say that you’ve wasted time on premature optimization, not to mention that you’ve probably had to spend time implementing all of that data access code.

I would rather use an ORM that has implemented everything that is difficult about data access. Now all I have to tell it how to map to the database (which isn’t that hard) and tell it to do things for me. With lazy loading, it won’t load entity relationships (e.g. child collections on an entity object) unless it needs to. It knows when objects are dirty and if they need to be saved or not. I have an easy hook so that I can validate entities when they are saved.

The other day I configured a cache in NHibernate in 15 minutes. With very little code I was able to set NHibernate up so that it will cache entities that don’t ever change in memory so that it doesn’t have to get to the database to get them every time. There were numerous examples on the internet telling me how to do this, and I’m extremely confident that it’s going to work (I didn’t have to write any of the difficult code for caching because NHibernate has solved that problem).

I want to write code that solves business problems. Thankfully other people have written libraries that will help me do that. So I’m going to use them.

I’ll be speaking on the SOLID software design principles at the Quick Solutions office (440 Polaris Pkwy., Suite 500, Westerville) on Wednesday, Sept. 16 from 5:30pm-to 7pm. In this talk, we’ll go through Uncle Bob’s “SOLID” software design principles, separation of concerns, a brief overview of inversion of control containers like StructureMap and Ninject, and more object-oriented goodness that will help you write better code.

There’s free food too. If you’re coming, please RSVP to amorey at quicksolutions dot com so that we can have enough food.

If you’re going to the Software Engineering 101 conference, this is basically the same talk that I’ll be giving there. So if you’re going to go to one, go to the Software Engineering conference since you’ll get lots of other good stuff there too.

In case you haven’t heard, the Software Engineering 101 Conference is going on in Columbus on September 23. This is a one-day event where you will learn about software design topics and techniques such as object-oriented programming and the SOLID software design principles as well as a super-special hands-on test driven development session! This is all good stuff that every developer should know and it will be well worth your time. Rather than recount all the details, I’ll let you read more on Jim’s blog.

This is a FREE event, so all you have to do is ask your employer if you can go, they don’t even have to pay anything for it. I feel like I say this a lot, but these skills are essential for any software developer and have revolutionized the way that I write code.

Registration is limited, and I expect that it will fill up relatively soon, so don’t wait! You can click here to register.

Most of us at some point have decided that we want to learn some new technology. The question is what you should dive into.

When I interview people, I always ask them about new things that they have been learning, and a lot of people these days are looking into things like WPF and Silverlight. But this is not what I would pick if I were you.

If you were to ask me, instead of learning some new technology, every developer should try to become experts in software design patterns and principles and practices that will help you become a better developer with the technologies that you already know. Our industry has a much bigger need for developers that write well-designed, loosely coupled, well-tested code than we need for people with a basic knowledge of WPF or Silverlight.

Look, there’s nothing wrong with learning WPF and Silverlight, and you can make some awesome looking apps with them. But if you can learn software design patterns and practices, those will help you when using any language for the rest of your career. They will help you write less bugs, they will help you get stuff done faster, and they will help you write flexible code that can easily be changed. Who doesn’t need more of that?

Like I said, I interview people. If I interview you and you know and practice things like test-driven development, the SOLID principles, what the Law of Demeter is, and why all of this matters, then you are most likely in (as long as there isn’t something else seriously wrong with you). In my opinion (and this is just my opinion), if you want to be called a “senior developer” I would expect you to know all of these things. This is much more important than how many years of experience you have.

This may require some research and leg work on your part. I say this because in my opinion, Microsoft doesn’t not actively promote this stuff. Sure, you might find some MSDN article out there that talks about testing or patterns or something like that, but there will probably be many times more articles about Silverlight, new features in .NET 4.0, and the like. All of that stuff is good, but I feel people are skipping over the essentials. You can probably pass any number of Microsoft certification tests without knowing much about test driven development or design patterns.

This is why I identify with the ALT.NET way of thinking. ALT.NET generally believes in these principles:

1. You’re the type of developer who uses what works while keeping an eye out for a better way.
2. You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.
3. You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.
4. You know tools are great, but they only take you so far. It’s the principles and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principles (e.g. Resharper.)

Promoting ALT.NET or starting some new kind of cool kids club is not the point. The point is that good software design practices and principles are very important (many would say of the utmost importance), much more important than the latest shiny new tool that is coming out. If the code you write is not well designed or well tested, that problem is not going away by moving to .NET 4.0 or Silverlight.

So if you want to learn good software patterns and practices, here’s where I would start:

• Learn how to do test-driven development. The best way is to have someone teach you how to do it because it’s hard to just read about it and pick it up (although you’re more than welcome to try!). If you don’t have someone to teach you, hopefully the next technical conference or Day of .NET or user group you go to will have a talk on how to do TDD. Go to it. I have lots of TDD links and some practice projects here.
• Learn the SOLID principles and why they’re important. You can go buy this book or just read everything on this page. Again, if you next conference/user group/etc. has a talk on SOLID (and a lot of them will), go to it.
• Read some of the “classics”, like some of the books mentioned here.
• Make sure you keep your ego in check. We should never stop learning, and should never be content with where we are now. There will always be something worth knowing that you don’t know.