Listening to the last screencast of Rob Conery (MVC Storefront) made me realize something that I haven’t really understood before.

Suppose you have the interface of a repository, let’s say IEntryRepository. Then you have the actual SqlEntryRepository and TestEntryRepository. When I am doing TDD, I am testing the TestEntryRepository. But it will not be used in production. Why bothering with testing it then?

Because TDD is a design process. Even if I am testing my code, I am also designing it. The SqlEntryRepository will benefits from the actual design of the repository we use for testing.

This is an interesting pattern. I was using it without giving it a name. I encountered this pattern while reading the Jimmy Nilsson’s book : Applying Domain-Driven Design and Patterns - With Examples in C# and .NET. The Unit Of Work is a way to create a logical group of object. The most basic example I can think of is the example of an Order. An order contains OrderLines. The Order and the OrderLines are part of the same logical group. We say that this is an Unit Of Work. I tend to think of it at the way I’ll save the Order. Do I call a service to insert the Order and another to save the OrderLines? Or do I call a single service that will persist it all at the same time (maybe using a transaction)? I will use a single service that will save the Order, the OrderLines and all other related information. Everything that must be persisted at the same time is said to be an Unit Of Work.

In the RecipeHelper project (the personnal project I am working on), I have a single Unit Or Work (at the moment). The Recipe is the root and contains a list of steps to follow and a list of ingredients. When I persist a recipe, I persist everything in the object graph.

Here is some resources from experts that can help you more with applying this pattern :

• P of EAA: Unit of Work
• NHibernate and Unit Of Work

I have always been told that TypeMock was too powerful, not strongly typed and for that, It shouldn’t be used. I believed that. The problem is : I should have given it a try before taking that for granted.

I have watched the Roy Osherove screencast and was impressed! I am currently working on an existing code base that was done before we went Agile and even before we were doing object-oriented development. When I need to refactor certain features I usually start writing tests and then using dependency injection to be able to mock some object. The minimum to be testable with Rhino Mocks. But with TypeMock you can mock object and don’t even need to inject them. You can also make expectation on static methods. Isn’t that just great! I believe so.

However, I will stick with Rhino Mocks for now. I like the way It force me to decouple my code and in some sense, it provide me with guidance to make my work testable.

P.S. : This is just my opinion and not the absolute truth.

Of course it does something, just make sure you call the Flush method on your session…

I have just started playing around with NHibernate for a personal project (the one I use for the Building a new application series) and I’m liking it. This make all the data access seems so easy. Maybe I will change my point of view after dealing with some collections and relationships.

Sometimes, you come across real treasure! This is one of them, printed and with me for a long time.

I have just finished reading the “Foundations of Programming” series by Karl Seguin. This is a “Must Read”. It’s a really great series that cover all aspect of building an application. I can’t recommend it enough!

Here is a link to the PDF file which has all seven posts.

For the getter, it’s exactly as you would do with a method :

Expect.Call(mockedConnection.CompanyConnectionString).Return("testconnectionstring");

For the setter, only assign the value you want to the property of the mocked object :

mockedConnection.ConnectionString = "testconnectionstring";</PRE


 

(Index of the whole series)

I have completely forgotten to show you the basic folder hierarchy of my solution. I invite you to try once to make a completely different folder hierarchy instead of the one Visual Studio suggest. Not that Visual Studio is a bad tool for this, not at all. I have learned that letting a tool do the folder management can lead on to unnecessarily complexity. Let me explain myself. There is an adage that say you should program into a language instead of programming in a language. Make Visual Studio work with your layout instead of using the default. I find interesting what you can learn when you organize yourself the layout of the solution.

Anyway, let’s see my folder structure :

The build folder is where the compiled application will reside. When doing automated testing I will use this version.

The config folder is where all the configuration files will be. I’ll probably get rid of it real soon as I have probably found a way that work better for me.

The lib folder contains library that are necessary for the project to be executed correctly.

The sql folder will contains all the sql script. This is also considered to be removed.

The src folder is composed of the app folder and the test folder. Each one contains a subset of all the projects (tests projects in the test folder and application in the app folder).

The tools folder contains any tools that are not necessary to execute the solution but are needed for the development.

It’s basically all I need for now to begin iterating on my application (using User Stories of course). I must mention that I doing this in an iterative way and a lot of things are subject to change. Any comments are greatly appreciated and will be read and considered.

I’m also considering to put all source file into Google Code. Stay tuned!

Talk only to your close friends. This is a object-oriented design guidelines. This law state that your object should know as little as possible of others objects. You may also know this by the name of “Principle of Least Knowledge”.

I have found that this guidelines has helped me a lot in my development. The more decoupled your object is, the easier it will be to make changes in your design.

• Wikipedia : Law of Demeter
• Law of Demeter

I strongly suggest that you apply this law. You’ll thank me later.

I’m looking right now for a way to remove dependency from my application and the solution seems to be the IoC pattern(Inversion Of Control) now know as dependency injection. A quick search in Google lead me to the Inversion of Control Containers and the Dependency Injection pattern article by Martin Fowler.

So in this article I have the choice of using the Dependency Injection pattern and use a framework like Spring, Avalon or the container called PicoContainer, or use the Service Locator pattern that use no other framework. A good argument is that with dependency injection, testing is much easier. There is no easy solution but probably give the Spring framework a try since it have other nice feature.