5

Note: I use C# as an example, but the problem is virtually the same in Java and probably many other languages.

Assume you implement a value object (as in value object pattern by M. Fowler) and it has some nullable field:

class MyValueObject
{   
    // Nullable field (with public access to keep the example short):
    public string MyField;
}

Then, when overriding Equals(), how do you treat the case when both value objects have their MyField set to null? Are they equal or not?

In C#, treating them as equal seems obvious, because:

  1. This is the behaviour of Equals() when you use a C# struct instead of a class and do not override Equals().

  2. The following expressions are true:

    null == null
object.ReferenceEquals(null, null)
object.Equals(null, null)

However, in SQL (at least in SQL Server's dialect), NULL = NULL is false, whereas NULL is NULL is true.

I am wondering what implementation is expected when using an O/R mapper (in my case, NHibernate). If you implement the "natural" C# equality semantics, may there be any ill effects when the O/R mapper maps them to the database?

Or maybe allowing nullable fields in value objects is wrong anyway?

Marco Eckstein
  • 4,448
  • 4
  • 37
  • 48
  • 1
    God help me understand why SQL forces people to use "is null" to mean "equal to null" instead of using the perfectly good "=" operator. In C# and most other lanuages, the objects are equal if both fields are null. (And in SQL too! They just force you to use "is" instead of "=") – Kirk Woll Dec 01 '10 at 02:30
  • I think the idea of the SQL NULL equality behaviour is that NULL may be anything. It has no clearly defined "real world" semantics. So, one NULL may "actually" be a missing 'foo' and the other NULL a missing 'bar'. Then, when comparing, SQL cannot know whether two NULLs are equal, and behaves conservative, which causes it to not consider the NULLs as equal. It doesn't consider them as unequal, either! NULL != null is false as well. In C#, on the other hand, null is simply an empty/ missing reference. – Marco Eckstein Dec 01 '10 at 02:52
  • @Kirk because by definition any comprison to NULL is false. In realtional algebra NULL means you dont know. So if I dont know the day I will die and you dont know the day you will die it doesnt follow that we will both die on the same day. – James Anderson Dec 01 '10 at 04:30

3 Answers3

1

Since ORMs know the relational model, they usually expose a way to query using SQL semantics.

NHibernate, for example, provides the is [not] null operator in HQL, and Restrictions.Is[Not]Null in Criteria.

Of course, there's an API where these paradigms collide: LINQ. Most ORMs try to do the right thing when comparing to null (i.e. replacing with is null), although there can be issues some times, especially where the behavior is not obvious.

Diego Mijelshon
  • 52,548
  • 16
  • 116
  • 154
0

Personally what I think is that if it can be null (in error free code), then they should be treated as equal. However, if it shouldn't be null(ie: a Name for a Customer, or a Street Address for a Delivery) then it should never get to null in the first place.

Programmdude
  • 551
  • 5
  • 22
0

I think you have two issues:

One being that you need to know if one instance of MyValueObject is equal to another instance.

And secondly, how that should translate to persistence.

I think you need to look at these separately as it seems that your angle is coupling them too close to each other which seems to me to violate some DDD principals - the Domain should not know/care about the persistence.

If you are unsure of the effect of the null value of MyField either (a) have it return a different Type other than string; (b) have it return a derivitave of string like EmptyString (or similar Special Case implementation); (c) or override the Equals method and specify exactly what it means for these instances to be equal.

If your ORM can not translate a particular expression (that involves MyValueObject) to SQL then perhaps its ok to do the harder work in the persistence layer (have the compare happen out of the SQL translation - yes, performance issues i know, but im sure not impossible to solve) in favour of keeping your Domain Model clean. It seems the solution should derive from "what's best for the domain model" to me.

@James Anderson makes a good point. Reserve null for error and failure states. I think Special Case seems more and more appropriate.

Matt Kocaj
  • 11,278
  • 6
  • 51
  • 79