bc_shout_thumb With the flat response from the series so far, I thought I’d stir the pot a little. Again, I am not trying to start a flame war, I just want to share my opinion and start a conversation about it.

I’ll start by saying that I am VERY comfortable using SQL. PL/SQL, T-SQL and even a bit of MySQL (ack). But after using NHibernate for the last year or so, I can honestly say that if I never write another sproc, I’ll be totally OK with that. I don’t think sprocs are evil, or ruin your application, for me it’s about testability. I like the fact that I can write a test that can check my query logic and never have to touch the database. I like the fact that I can test all four basic CRUD operations with one line of code! Most of all, I like doing it in C#.

There are times when there is no good substitute for a good sproc. But for most applications, I don’t see the point. SPECIALLY for CRUD operations.

What do YOU think?

It’s true, I swear. It’s very simple to test if you can (C)reate, (R)ead, (U)pdate and (D)elete objects using NHibernate, and Fluent NHibernate makes it one (fluent) line of code!

Suppose we have an Employee object and we want to check that we can CRUD it AND reference to the Company (object) they work for in the mapping. It might look like this:

   1:  new PersistenceSpecification<Employee>(Session)
   2:      .CheckProperty(x => x.FirstName, "Dave")
   3:      .CheckProperty(x => x.LastName, "Jones")
   4:      .CheckProperty(x => x.MiddleInitial, "L")
   5:      .CheckProperty(x => x.DateOfBirth, new DateTime(2008, 11, 1))
   6:      .CheckProperty(x => x.Sex, _sex)
   7:      .CheckReference(x => x.Company, new Company{ CompanyID = 999, Name = "Wonder Wheels" })
   8:      .VerifyTheMappings(); 

Okay, it may not LOOK like one line of code, but I swear it is. One, long, fluent line of code.

Super sweet. If you’ve found better ways, post a comment, I LOVE to learn better ways.

 

~L

That’s right, I said it, I’ve been doing it, and I abso-effin-lutely love it.

A few months ago my co-worker, Troy, posted a question on Stack Overflow. We were doing integration testing on a project we were working on, and as the object graph grew larger, the code required to test query logic became painful. Since I am a sissy and don’t like pain, Troy asked the question on SO about how we might do it less painfully, and we got this answer, and it totally changed our TDD/BDD lives.

The answer came from Garry Shutler, here and I’ll just sort of re-iterate it.

We created a base Interface for our repositories IRepository<T>, with a method IQueryable<T> All(). like so:

   1:  public interface IRepository<T>
   2:  {
   3:      IQueryable<T> All();
   4:      // whatever else you want
   5:  }

 

Then we implement it like so:
   1:  public IQueryable<T> All()
   2:  {
   3:      return session.Linq<T>();
   4:  }

We can then mock the IRepository<T>:

   1:  _repository = MockRepository.GenerateMock<IRepository<Customer>>();

 

Then Stub it to return a predefined list of objects that we are searching
   1:  _repository.Stub(repo => repo.All()).Return(TestCustomers.All().AsQueryable());

 

Then we can test the login of a Customer search by:
   1:  [Test]
   2:  public void should_return_customers_matching_first_name_last_name_and_dob()
   3:  {
   4:      Assert.That(_returnedMatches.Contains(_firstNameLastNameDOBMatch));
   5:  }

 

 

 

 

 

Many thanks to Garry for all the time he saved us, I immediately subscribed to his blog and have not been disappointed. I hope this helps someone as much as it has helped us.

~L