http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Because it doesn't always work. Null is a missing value, in which case the rule is invalid. NullValue pattern implies that it should still work, which is not always the case. As a simple example, how would you handle a rule that give 2% discounts for customers after 6 years ? http://ayende.com/3576/nullifying-null#comment15http://ayende.com/3576/nullifying-null#comment15Sun, 07 Sep 2008 22:06:43 GMTI tend to agree with Roger that the null value pattern fits nicely... after all an anonymous customer is still a (non-preferred) customer and your domain should reflect that. Out of curiosity, for what reasons is the null value pattern not a good option? http://ayende.com/3576/nullifying-null#comment14http://ayende.com/3576/nullifying-null#comment14Sun, 07 Sep 2008 19:32:22 GMTRoger, he pointed it out here: "We can also decide to return a default instance of the customer when it is not there,...." That's the nullable pattern. http://ayende.com/3576/nullifying-null#comment13http://ayende.com/3576/nullifying-null#comment13Sun, 07 Sep 2008 06:11:23 GMTOk I must be blind, because I didn't see that you pointed out null object the first time I read it. Either way. I'd say that there are two major benefits for using null object here. 1) The person that performs an anonymous checkout isby definition a "customer" since he is buying from you. So it would be extremely odd to not model this into the domain. 2) Nullifying rules because of state is not very obvious for the reader of the DSL script. This breaks the rule of least surprise (IMO) Even if the intent is to lessen the burden on the DSL writer, I'd guess that this will be more error prone because people could make incorrect assumptions on state and expect that certain blocks of code have been executed when they have infact just been ignored. http://ayende.com/3576/nullifying-null#comment12http://ayende.com/3576/nullifying-null#comment12Wed, 03 Sep 2008 13:54:58 GMTRoger, I am doing both. Exposing the domain directly to the DSL make it easier to work with it. On the other hand, it hurt versioning and the fluidity of the language. http://ayende.com/3576/nullifying-null#comment11http://ayende.com/3576/nullifying-null#comment11Wed, 03 Sep 2008 11:38:41 GMTRoger, Yes, I did pointed that one out. That is one option to deal with that, but it is not always a good option. http://ayende.com/3576/nullifying-null#comment10http://ayende.com/3576/nullifying-null#comment10Wed, 03 Sep 2008 11:37:16 GMTI think 'null' (UnregisteredCustomer) object may be easier in this case (with IsRegistered false to check that if something depends on fact of having a known Customer). http://ayende.com/3576/nullifying-null#comment9http://ayende.com/3576/nullifying-null#comment9Wed, 03 Sep 2008 06:14:58 GMTAlso, are you exposing your "real" domain model to the DSL? So that the DSL could invoke code in the domain that is not supposed to? Or are you transforming a subset of the domain into some sort of readonly mini DM for the rule engine? http://ayende.com/3576/nullifying-null#comment8http://ayende.com/3576/nullifying-null#comment8Wed, 03 Sep 2008 06:05:44 GMTWhy not simply use the null object pattern in this case? I cant say I use null object much myself, but in this kind of scenario it might be a more robust approach, making the life for a rule writer easier. Just because you don't have a anonymous customer in your persistent store doesnt mean you can't expose one to the rule engine. http://ayende.com/3576/nullifying-null#comment7http://ayende.com/3576/nullifying-null#comment7Wed, 03 Sep 2008 06:00:54 GMTpb, While the second is possible (and is mostly what I did today), I strongly recommend against it. Trying to understand how it works is hard. 1) is an eye sore. It is easier to say that if Customer is null, the rule is not evaluated. (To be rather more exact, it is known that if customer is null, the rule evaluate to false). Since this applies to just about any property, where there can be many, it is simpler overall, I think. http://ayende.com/3576/nullifying-null#comment6http://ayende.com/3576/nullifying-null#comment6Wed, 03 Sep 2008 02:03:43 GMTI get trying to make it easier to read, but this kind of hides something somewhat important, that you'd have to figure out when your rules weren't doing what you thought. I think I'd rather see either 1) Just add a "not Invalid(Customer)" to the beginning of each when 2) a rule about rules, such as: for_all_whens return_false_if Invalid(Customer) so it was all clear what was going on. That seems possible given the code you've posted so far. Maybe you're just trying to do this as a simple example of a more complicated concept you have going on though. http://ayende.com/3576/nullifying-null#comment5http://ayende.com/3576/nullifying-null#comment5Wed, 03 Sep 2008 01:59:56 GMTpb, That is actually easy. OnIsExpression => x => isExpressions.Add(x.Name) Now you just check if it is there. http://ayende.com/3576/nullifying-null#comment4http://ayende.com/3576/nullifying-null#comment4Wed, 03 Sep 2008 01:04:56 GMTFine as long as you don't need a rule that reacts to it being null and doing something... http://ayende.com/3576/nullifying-null#comment3http://ayende.com/3576/nullifying-null#comment3Wed, 03 Sep 2008 00:54:36 GMTPaul, I makes some assumptions about you being able to understand AST, I admit. http://ayende.com/3576/nullifying-null#comment2http://ayende.com/3576/nullifying-null#comment2Wed, 03 Sep 2008 00:42:50 GMTWhile the solution you posted may be succinct it is far from simple for anyone new to .net. I've only been doing c# .net for a year but I've been programming for 9 years so I think I can say you would need to comment the hell out of that code. http://ayende.com/3576/nullifying-null#comment1http://ayende.com/3576/nullifying-null#comment1Wed, 03 Sep 2008 00:06:58 GMT