Is it possible to prevent EntityFramework 4 from overwriting customized properties?

Question

I am using EF 4 Database first + POCOs. Because EF has no easy way to state that incoming DateTimes are of kind UTC, I moved the property from the auto-generated file to a partial class in another file.

    private DateTime _createdOn;
    public virtual System.DateTime CreatedOn
    {
        get { return _createdOn; }
        set
        {
            _createdOn =
                (value.Kind == DateTimeKind.Unspecified)
                    ? _createdOn = DateTime.SpecifyKind(value, DateTimeKind.Utc)
                    : value;
        }
    }

However, now every time I update the model, the automated properties get created again in the T4-generation. Of course this causes the following compilation error: "The type 'Foo' already contains a definition for 'CreatedOn'".

Is there any way to tell EF to not generate that property and to let me handle it on my own?

Update

Thanks for everyone's answers...

I created a new custom property with a different name.

    public virtual System.DateTime CreatedOnUtc
    {
        get
        {
            return (CreatedOn.Kind==DateTimeKind.Unspecified)
                ? DateTime.SpecifyKind(CreatedOn, DateTimeKind.Utc)
                : CreatedOn;
        }
        set
        {
            CreatedOn =
                (value.Kind == DateTimeKind.Unspecified)
                    ? CreatedOn = DateTime.SpecifyKind(value, DateTimeKind.Utc)
                    : value;
        }
    }

I also set all of the setters and getters of the auto-generated property to Private with the exception of those properties that I needed to use in a Linq-to-Entities query (sigh). In those cases, I set those getters to internal.

I sure wish there was a dropdown on DateTime types to specify what "Kind" of DateTime that EF should treat it as. That would have saved hours and the extra complication.

Solution 1

I think things start to get messy if you try to manually modify EF generated classes.

There are two options that I'd suggest pursuing:

1. Don't modify the existing property, but add a new one to your partial class, CreatedOnUTC or something similar.
2. Modify the T4 template to alter the way that it generates the accessors for these date properties (easier if every DateTime property is to work the same way). It won't be trivial, since it's type dependent, but would at least allow you to use the generator in future.

Solution 2

A different approach is to hook into the ObjectMaterialized event in the DbContext and set the kind there.

In my DbContext constructor, i do this:

    ((IObjectContextAdapter)this).ObjectContext.ObjectMaterialized += new ObjectMaterializedEventHandler(ObjectMaterialized);

and then the method looks like this:

private void ObjectMaterialized(object sender, ObjectMaterializedEventArgs e)
        {
            Person person = e.Entity as Person;
            if (person != null) // the entity retrieved was a Person
            {
                if (person.BirthDate.HasValue)
                {
                    person.BirthDate = DateTime.SpecifyKind(person.BirthDate.Value, DateTimeKind.Utc);
                }
                person.LastUpdatedDate = DateTime.SpecifyKind(person.LastUpdatedDate, DateTimeKind.Utc);
                person.EnteredDate = DateTime.SpecifyKind(person.EnteredDate, DateTimeKind.Utc);
            }
        }

The downside is that you need to make sure you set it for each property that you care about but at least it gets set at the lowest possible level.

Solution 3

I used the same approach as Michael only then I dived a little bit deeper, and used reflection to search for DateTime and DateTime?

My solution to ensure that all the DateTime values are readed as Utc DateTimes is as followed:

First I wrote three methods which are in my DbContext Extensions method class. Because I need to use it for multiple DbContexts

public static void ReadAllDateTimeValuesAsUtc(this DbContext context)
{
        ((IObjectContextAdapter)context).ObjectContext.ObjectMaterialized += ReadAllDateTimeValuesAsUtc;
}

private static void ReadAllDateTimeValuesAsUtc(object sender, ObjectMaterializedEventArgs e)
{
    //Extract all DateTime properties of the object type
    var properties = e.Entity.GetType().GetProperties()
        .Where(property => property.PropertyType == typeof (DateTime) ||
                           property.PropertyType == typeof (DateTime?)).ToList();
    //Set all DaetTimeKinds to Utc
    properties.ForEach(property => SpecifyUtcKind(property, e.Entity));
}

private static void SpecifyUtcKind(PropertyInfo property, object value)
{
    //Get the datetime value
    var datetime = property.GetValue(value, null);

    //set DateTimeKind to Utc
    if (property.PropertyType == typeof(DateTime))
    {
        datetime = DateTime.SpecifyKind((DateTime) datetime, DateTimeKind.Utc);
    }
    else if(property.PropertyType == typeof(DateTime?))
    {
        var nullable = (DateTime?) datetime;
        if(!nullable.HasValue) return;
        datetime = (DateTime?)DateTime.SpecifyKind(nullable.Value, DateTimeKind.Utc);
    }
    else
    {
        return;
    }

    //And set the Utc DateTime value
    property.SetValue(value, datetime, null);
}

And then I go to the constructor of my WebsiteReadModelContext which is a DbContext object and call the ReadAllDateTimeValuesAsUtc method

public WebsiteReadModelContext()
{
      this.ReadAllDateTimeValuesAsUtc();
}

Solution 4

I would use the edmx and specify another name for the CreatedOn property (such as CreatedOnInternal). Then set the access modifier for generation to Internal instead of Public. Then you can implement your custom property in the partial class and not worry about this.

Solution 5

EF can be pretty nasty sometimes when it comes to stuff it generates.
In Database First applications when I encounter a similar problem I usually follow this approach:

• Leave autogenerated properties but make them private and change their names;
• Add public “wrapping” properties that make sense for the business code.

For example, I would rename CreatedOn to something else, like CreatedOnInternal (credits to Jeff) and mark it private in the designer. In the partial class, I would add a public CreatedOn wrapper property that does the conversion back and forth.

View more solutions

Comments

[Dan Abramov]

I just realized Jeff already posted this idea, and since his naming suggestion was better than mine, I edited my answer.

[Jason]

Thx @steve. I went with option 1. I'm just bummed that something so integral to the semantics of the DateTime value isn't a simple drop down option in the edmx.

[Jason]

Clever but I would worry about performance using reflection. Nothing that a little profiling wouldn't help you see if it was worth worrying about.

[Jason]

I think I would lean towards this method were I to come across this problem again. Thanks.

[Robert Sirre]

Nice as a quick fix, the other way around, for storing Dates and Times requires another hook for asserting DateTime kinds.

[Robert Sirre]

I think ObjectContext.SavingChanges can be used for this. (Additional logic for how to treat 'local' dates needs to be added). I think that @Jason is right with his performance concerns, but for now this suffices for me. A better way would be to edit the TT templates, removing the need for reflection.

[Matt]

Good answer. @All: If you want to know how 2. works in detail, check out this link.

[Anthony Wieser]

I tried to use this approach, but found that it didn't work at all for me. What I had to do to get it to work was specify that DateTime objects were specified as Ticks in the Connection String adding this: "datetimeformat=Ticks;" . After that, it did work.

[Morten Mertner]

It turns out that the true cost of this is actually accessing the IObjectContextAdapter.ObjectContext property, as this will trigger expensive operations inside EF. A mere 400 DbContext creations took well over 6 seconds here.

[Brannon]

I believe that using ObjectContext should only be expensive on the first call, at which point it will establish the database connection. It's the same expense that you would incur with your first read or write. True?

[Suncat2000]

If you cached the affected properties the first time they were accessed, then the cost of reflection would be small. Class types shouldn't change their structures at runtime.

[Niklas Peter]

This considers retrieving entities from the DB, but not storing them.