I agree to a large degree. But it's a shame that this behavior exists and we can't control it. Default values in the database can greatly simplify this behavior and reduce the amount of client code that has to run.

As I mentioned I have this partially fixed with a flag on my BO which can automatically fill everything with blanks. This at least lets me handle the 90% case automatically only occasionally requiring a manual override in the BO code...

For real business type logic (rather than a simplistic default value) I would always choose to put defaults into the bus object.

I'm in general not a strong believer in putting too much logic into the database even if it does provide better performance in many cases. It's just more consistent with an OO architecture to have this logic in the BO layer of the app.


+++ Rick ---


>Hi Rick,
>
>>Right now as it stands I have a routine that initializes most values to
>>non-null values then explicitly follow up the fields that need to have
>>specific values (or null) set. It's not a big deal, but this sort of thing seems very inefficient requriing lots of extra code... (well actually my BO has some code that can do this automatically setting everything to VFP style blanks rather than nulls).
>
>I don't have an answer w.r.t. ADO.net, but in general I've been concluding lately that default values ideally should not even be under the control of the back-end, but rather should be controlled by the BO in the first place. Well, at least whenever you have control over both tiers...
>
>>Dealing with NULLS in ADO.NET is a PITA too because you have use DBNull for all comparisons etc. so I'm even less inclined to ever use NULLs in any data except those that REALLY require it for knowledge of previously unset values (most don't).
>
>In a way, I have the same feeling about NULLS as default values. The BO really needs to make these calls. Of course, you have to do something in the backend to allow NULLs, but beyond that, I really want my BO to control this stuff rather than being faced with the anguish having my data-access strategy limit what I "know" about my data entities.
>
>-- Randy