Whats better design/practice: Nullable property or 1 value property and 1 bool "has" property?

I'm working on an ASP.NET MVC app, designing the domain models, using (testing) the new EF Code First feature.

I have an Activity entity that may or may not have a Deadline, what is the best way to approach it?

1 property:

public DateTime?  Deadline {get; set;}
and check vs 开发者_C百科null before using

or

2 properties:

public DateTime Deadline {get; set;}
public bool HasDeadline  {get; set;}

At first I thought of the first option, but then I started thinking that maybe the second option would be better regarding the DB...

Is there any best practice regarding this?

I'd go with the first option. After all, it's exactly an encapsulated form of the second.

The encapsulation makes it clear that you've only got one logical value (or lack thereof). In the second form you can treat the properties as if they were entirely independent, which they're logically not.

In terms of the database, I'd expect the first form to be just as easy too... presuambly you'll have a nullable DATETIME field in the database, won't you? It should map directly.

How about a combination of both just for the sake of making your code more readable?

public DateTime? Dealine{get; set;}
public bool HasDeadline
{
    get
    {
        return (Deadline != null);
    }
}

Its easy to read and does exactly the same thing that the consumer would have to do anyway. Besides...

if(HasDeadline)
    doStuff();

is easier to read than

if(Dealine != null)
    doStuff();

:)

I would use the first option. In the long run the second option will probably cause some maintenance problems because you have to remember to check and use both of the properties.

Also one option is to use one property but instead of making it nullable, you could return a Null object (also known as Special Case).

The database is used to storing NULL values - storing a Min value in the databsae, and then having a flag to indicate if you should trust that value makes queries complicated.

I like nullable types since the reflect the domain's intent - there is no date, not 'there isn't a date, so pretend the first of January 1970 means no date'.

There is also an overhead of maintaining the HasDealine value - you need to set it each time the corresponding property is updated. Also how do you clear it? If you set the Deadline to a date, it will set the HasDeadline to true. How do I 'unset' it? Would you set HasDeadline to false, but leave the Deadline field intact with the previous value?

Overall icky.

You should use the nullable, as it does exactly what you want. Using two separate properties means that you lose the connection between them, and you need to explain with documentation that they have a relation.

The nullable type should also fit better against a database type, however you should first design your object for how it works as an object, not for how you will store it in the database. If the use of a database generation tool causes you to make bad decisions when designing the code, it's contra-productive.