System.DateTime is a value type, and as such, cannot be null. The default value for DateTime in .Net is DateTime.MinValue, which equals to 01/01/001 00:00. The problem is that SQL Server's dates start at 1753, or there about.

This is usualy solved in .Net 2.0 using Nullable<DateTime> (or DateTime? in C#), but my "entities" are messages to web services, and are generated from WSDL, so they lacked this nice feature. I also didn't realize that some of the DateTime values were nullable until pretty late into the game.

After a lot of head scratching, I came up with this solution, which utilizes NHibernate's IInterceptor capabilities. The interceptor allows to get the raw data before it is loaded and after it is saved, and interfer with it. Using that, I got this DefaultDateToNullInterceptor:

The OnSave() and OnFlushDirty() methods are called before the values are saved or updated (respectively). The MinValueToNull() method is very simple, it replace all instances of DateTime.MinValue with null, like this:

All that was left was openning the session with the interceptor, and I was set.

The worst part of building a distributed application is that you get different state in different parts of the system. Let us take a look at a simple message passing application, and the issues there. At the end of the day, each and every message should arrive once, and exactly once. I am assuming that it is not possible for the message to be corrupted in transmissions (The TCP/IP stack in general makes sure that you won't see those messages).

The simplest model is where everything works out great:

A common scenario is that the sender failed to send the message:

A simple resolution is sending the message again, and again, until you get an OK reply back. But then there is the dropped reply scenario, the reciever got the message, but the reply was dropped. As far as the sender knows, the reciever never got the message:

A naive implementation on the reciever side will lead to the duplicate message scenario, but a slightly less naive implementation, which detects and errors on duplicate messages may result in a lot more headaches in the end, consider this scenario:

The sender never recieves an OK reply for his message, so it will send it to the end of the days. The reciever got the message the first time and replied just fine, but the sender persist trying to give it duplicate data, which means that it keeps returning error messages back.

A good way to prevent that is to check before sending, like this:

Assuming that we always keep this semantics, a failure at any points of the road never leads to losing messages or duplicating them. I tried, but I can't think of a way the sender will think that the reciever got a message when the reciever didn't get it.

Just to point out, the scenario above happens all the way up from TCP. This is a relatively simple scenario. More interesting ones include ordered messages, and two ways communications.

Hope you liked the pretty pictures.

I just had a discussion about server side programming complexity vs client side programming complexity.

I hold the view that doing client side programming in an order of magnitude harder than doing stuff server side.

I was shocked to see this proof of my correctness:

And yes, I realize this is a falacy.

One of the big advantages to state based testing is the clearer error messages, like this:

Using interaction based testing, you usually can specify much less information:

Is this a setup code? Is this the expected result of the test?

Who knows? Certianly not me in tree weeks (or months) times, when this test is broken and I need to figure out why.

I am thinking about adding a Message construct to Rhino Mocks, which wil allow to specify messages that clarify the intent of the developer. Something like this:

There are some implementation issues (what happen when you get called too much, for instnace), but they should be workable. But before I try to add this, I would like some thoughts about the value of this feature.

Applying Domain-Driven Design and Patterns: With Examples in C# and .NET

Couple of disclaimers before I continue:

• I got a free copy of this book to review.
• I am probably not in the intended audiance of the book.

Nearly a month and a half ago, I posted my initial impressions from this book, which were good (even if it didn't come out like that). It took me quite a bit more to read it than the usual, mainly because I was swamped with work.

Anyway, the book declares itself as a guide to develop sofware using DDD. In fact, it covers much more ground than that, including patterns, inversion of control, testing, high and low level design, and more.

The overall tone of the book is very... relaxed. It felt at times like I was reading a long blog post, which meant that I had no problem with reading it on/off for a long time. The material is presented in a very approachable way, including a lot of details and explanations about what is going on.

I particularly liked the side notes where there are critiques on the code, some from Jimmy and some from other reviewers (This approach had this and that disadvantages, but I am using it because of the following reasons..., etc).

The first part of the book is an introduction to the concepts that are used throughout the rest of the book, patterns, TDD, domain concepts, etc. This was mostly repeating stuff that I knew, but it is a point to Jimmy's point that he managed to present the material in a way that was interesting even when I already knew what he was talking about.

The second part is where I consider the meet and bone of this book, covering how to apply DDD. The general architecture that is presented is similar to what I consider as ideal at the moment, and close to what I am trying to build in several applications at the moment. This part also straighten out some concepts that I didn't quite manage to understand from Evan's DDD book. Specifically, the relationships between the domain model and services and how to use them. I got several good ideas from this part, and it is responsible for my NHibernate Query Generator.

What I didn't quite like is the 7th chapter, about business rules. Partly this is because I'm currently invovled in an effort to implement fairly complex business rules implementation, and I don't think that the approach presented can hold in the face of the more complex scenarios. (Think of a case where you got heirarchical rules that are time dependant executing over a domain model that is timing sensitive. If you said Yuck!, I agree ;-)).

The forth part is talks about persistance, how to prepare to it, and how to implment it using NHibernate. I mostly agree with what was preseneted, and I was very surprised to learn new (and exciting) stuff about NHibernate (did you know that the mapping can declare Assembly and Namespace attribute seperatedly?).

The last part talks about moving the design forward, and how to take the domain design into the UI layer, and give the users a chance to take advantage of that as well.

What I didn't like:

Jimmy tries hard not to fall into the trap of using a specific product to show the concepts he is talking about. While it is a good approach in general, I felt at times that he is attempting it too hard. It might have been preferable to show the concepts using a certain tool, and mentioning how other products are solving similar problems.

There isn't any real refinement of the domain model as a result of new requirements or better understand of the client's model. The changes presented were changes mostly driven by technical decisions, not different way to understand the model.

Evans' DDD book made use of the shipping industry, with the difference being changing from focus on moving the cargo around, to moving the legal responsability for the cargo. I didn't see any such example in the book, and this is a core part of DDD.

Conclution:

I don't think that the title is doing the book justice. It is not nearly about DDD as about the whole approach to develop applications.

I tried to pinpoint who exactly will not benefit from this book, and I couldn't quite put my finger on it. If you are currently busy building application based on Evans' DDD, with full usage of TDD and are familiar with Fowler's Patterns of Enterprise Applications, you will probably not get much out of this book.

If you are a "standard" .Net developer, and by that I mean that you mainly used Microsoft's prescribed tools and practices*, you will get quite a bit of insight from reading the book. I intentionally do not limit this to intermediate (whatever that means) developers, since it is more about a shift in thinking than about the level of code required.

I am certainly going to circulate this book to other developers in my team.

Great job, Jimmy.

* And I don't need to tell you what I think about most of them, do I?

Using IRepository(Of Customer):

Using CustomerRepository:

The difference is the level of abstraction that is used. In the first case, the code define the question explicitly, using the generic repository to pose the question. In the second, it is the CustomerRepository responsability to get the data.

The first is much more flexible, but it is harder to test. The second is much easier to test (but require better integration testing to check that it the repository is actaully doing its job), and is more intention revealing.

I just spent four minutes configuring AdBlock to remove annoying ads from this page, I don't have an issue with normal advertising, but naything that blinks, jumps, etc is annoying.

I am not going to pay positive attention to stuff that annoys me. The end result that I don't know what the ad was about (it was big and black and green, that is all), but just about any ad server from this page is forever blocked on my browser.

Scott Hanselman's 2006 Ultimate Developer and Power Users Tool List for Windows was just published, and a mere cursory look revealed this gem:

Query Express - Useful SQL Client with no installation and only 100Kb of size. Perfect for putting on a server where you can't instal Management Studio, and perfect for my current situation.

Following Alex's post about traps in interviews, I thought about posting bits of code that I won't use in interviews. Mostly because I don't think that it is fair to the interviewee. I can think about crazy usages to langauge features, and not in a good way.

Consider the following peice of code (which is valid C# 2.0):

How would you use this method, and what is wrong with it?