Lower Or Equal To 'DateTime.Now' Rule Implementation.

[rxelizondo]

Hello,

Problem:
Our current design has a business object called Part that contains a ManufacturedDateTime property. Ideally, this property should contain the date time when the part was manufactured. The problem is that every once in a while an operator will incorrectly enter a data time value that falls way into the future and this creates significant problems for us.

Our Current Solution To This Problem:
To stop this from happening, we created a rule that stops a future date time from being entered. Essentially something kind of like this (note that the code below is just exemplary, it is not an actual implementation):

// Rule execution code.
protected override void Execute(RuleContext context)
{
    var someDate= (DateTime)context.InputPropertyValues[SomeDateProperty];
    if (someDate > DateTime.Now)
    {
        var message = "No future date times are allowed.";
        context.Results.Add(new RuleResult(RuleName, PrimaryProperty, message) );
    }
}

Concerns:
Although the rule works, something just does not feel right about it. For example, its weird that given the same property input, the rule may pass or fail depending on the current value of DateTime.Now. There is also another weirdness, the rule really needs to be checked right before the user Saves the object (not when the property value is set). This is because the act of saving needs to define the DateTime.Now value when the rule is checked (at least that is how we feel about it). There are other weirdnesses happening but lets not get to hung up in the details.

Suggestions Needed:
Could someone suggest how to properly solve the problem that we are having?

Thanks.

[hurcane]

We have many places in our business rules where the user is not allowed to enter a future date, or must enter date less than the current date. We've adopted the "good enough" philosophy. If it works for the normal business cases, there isn't a need to over-engineer the solution. The developers have had debates considering theoretical cases such as when the user started the data entry at 11:59 PM but didn't save until after midnight. Over time, we realized that most of these scenarios don't really matter to the end user.

You didn't mention when the rule executes. We often restrict this kind of rule to only run when the property is changed.

We also have scenarios where the property can be edited after the object is saved, but we don't want to allow the date to be later than the date that the record was created. We handle this by implemented a DateAdded property and including that in the rule, with the consideration that we use DateTime.Today when the DateAdded property is null.

[rxelizondo]

@hurcane: Thanks for your reply.

The consensus among us is to execute the rule right at the moment the object is being saved, the reason for this is the same reason you cited in your comments:

The developers have had debates considering theoretical cases such as when the user started the data entry at 11:59 PM but didn't save until after midnight.

To paraphrase, its ok for the operator to fill the form ahead of time (using a future date time). Because of this, we force the property rules to execute the moment the operator saves the object so that the rule executes against the time when the object is being saved... its kind of messy since the UI has to be the one asking to re-run the rule (not the business object) but it works. By the way, in case you are curious, we cant re-run the rule from the business object (via a Save override or similar) because we don't call Save until we know there are no broken rules and re-checking the rules during the Save operation in the business object may fail if that particular rule is broken after it re-runs. So we issue a rule re-check from the UI first, check there are no broken rules and then issue a Save.

You got me thinking though, perhaps the solution is to capture the a DateAdded property as you suggested and then update the rule so that the value is not allowed to exceed 1 our 2 hours from such DateAdded property value.... not sure, I still like the idea of just in time checking for our particular situation.