In our database we want to support NULL values instead of default 0 or MinValue. As we have to initialize every property with a default value - numeric fields are shown as 0. But as we showed the initial version to our client, they are not willing to accept it. Lets say, we have a value of 'Quoted Amount' and 'Shipment Date'. But due to business rule, users can leave the fields blank initially... As we have shown 0 and Min. Date in the fields - its not accepted. But incorporating Nullable<T> types using current CSLA framework seems difficult for a small team like us.
Can anyone shed some more light...how we can implement NULLable types easily without incurring much overhead?
I'm afraid that Nullable<T> is the technology Microsoft created to solve your issue.
The only alternative is to use the older technique of having all your properties be of type Object.
Either way you need to write code to translate an empty textbox to be a null, and a null to be an empty textbox. The simplest technique is to subclass TextBox and create your own control. Another technique is to handle the Format and Parse events from the binding object for each textbox control.
Other people may have further insights - but the point is that Nullable<T> is designed to solve this issue, so it is the right answer.
(Oh, and don't use SafeDataReader obviously! The whole purpose of that type is to get rid of nulls, and so it is useless for you!)
Its too much involvement, right? I have to make the private variables in the class as Nullable<T>, then make the property as Nullable<T>, read from DataReader and handle Null cases. Also while saving check whether its Null.
Keeping everything same using CSLA - can I have the same effect by handling parse and bind? I am curious to know what others are doing...
Since you are discussing Nullable<T> in C# syntax, you
could consider using int? and the other C# types that provide syntactic sugar
over Nullable<T>.
You could also consider creating something like SafeDataReader
that would have methods like GetInt32N(): returning an int? instead of int.
That’d keep your object code simple.
You still have the UI issue though, because many controls don’t
know what to do with a null, so you may still have to handle format/parse in
some cases (in other cases you can set a property on the control to tell it how
to handle null values).
Rocky
From: Mahmud
[mailto:cslanet@lhotka.net]
Sent: Monday, May 14, 2007 10:47 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Support of NULL
Its too much involvement, right? I have to make the private variables in the
class as Nullable<T>, then make the property as Nullable<T>, read
from DataReader and handle Null cases. Also while saving check whether its
Null.
Keeping everything same using CSLA - can I have the same effect by handling
parse and bind? I am curious to know what others are doing...
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.0/803 - Release Date: 5/13/2007 12:17
PM
Copyright (c) Marimer LLC