Search
Close this search box.

EF4 Code First Control Unicode and Decimal Precision, Scale with Attributes

There are several attributes available when using code first with the Entity Framework 4 CTP5 Code First option.  When working with strings you can use [MaxLength(length)] to control the length and [Required] will work on all properties.  But there are a few things missing. By default all string will be created using unicode so you will get nvarchar instead of varchar.  You can change this using the fluent API or you can create an attribute to make the change.  If you have a lot of properties, the attribute will be much easier and require less code.

You will need to add two classes to your project to create the attribute itself:

 : public class UnicodeAttribute : Attribute
   : {
   :     bool _isUnicode;
   :  
   :     public UnicodeAttribute(bool isUnicode)
   :     {
   :         _isUnicode = isUnicode;
   :
   }
   :  
  :     public bool IsUnicode {
     get { return _isUnicode; }
   }
  :
 }
  :  
  : public class UnicodeAttributeConvention : AttributeConfigurationConvention<PropertyInfo, StringPropertyConfiguration, UnicodeAttribute>
  : {
  :     public override void Apply(PropertyInfo memberInfo, StringPropertyConfiguration configuration, UnicodeAttribute attribute)
  :     {
  :         configuration.IsUnicode = attribute.IsUnicode;
  :
  }
  :
  }

The UnicodeAttribue class gives you a [Unicode] attribute that you can use on your properties and the UnicodeAttributeConvention will tell EF how to handle the attribute.

You will need to add a line to the OnModelCreating method inside your context for EF to recognize the attribute:

1 : protected override void OnModelCreating(
        System.Data.Entity.ModelConfiguration.ModelBuilder modelBuilder) 2 : {
  3 : modelBuilder.Conventions.Add(new UnicodeAttributeConvention());
  4 : base.OnModelCreating(modelBuilder);
  5:
}

Once you have this done, you can use the attribute in your classes to make sure that you get database types of varchar instead of nvarchar:

[Unicode(false)]
   : public string Name { get; set; }

Another option that is missing is the ability to set the precision and scale on a decimal.  By default decimals get created as (18,0).  If you need decimals to be something like (9,2) then you can once again use the fluent API or create a custom attribute.  As with the unicode attribute, you will need to add two classes to your project:

  }
  11 : 12 : public int Precision {
    get { return _precision; }
  }
  13 : public int Scale {
    get { return _scale; }
  }
  14:
}
15 : 16 : public class DecimalPrecisionAttributeConvention
    : AttributeConfigurationConvention<
          PropertyInfo, DecimalPropertyConfiguration, DecimalPrecisionAttribute>
    : {
  :     public override void Apply(PropertyInfo memberInfo, DecimalPropertyConfiguration configuration, DecimalPrecisionAttribute attribute)
  :     {
  :         configuration.Precision = Convert.ToByte(attribute.Precision);
  :         configuration.Scale = Convert.ToByte(attribute.Scale);
  :  
  :
  }
  :
}

Add your line to the OnModelCreating:

.ModelConfiguration.ModelBuilder modelBuilder)
   : {
   :     modelBuilder.Conventions.Add(new UnicodeAttributeConvention());
   :     modelBuilder.Conventions.Add(new DecimalPrecisionAttributeConvention());
   :     base.OnModelCreating(modelBuilder);
   :
   }

Now you can use the following on your properties:

1 : [DecimalPrecision(9, 2)] 2 : public decimal Cost 1
    : [DecimalPrecision(9, 2)] 2 : public decimal Cost { get; set; }

Both these options use the same concepts so if there are other attributes that you want to use, you can create them quite simply.  The key to it all is the PropertyConfiguration classes.   If there is a class for the datatype, then you should be able to write an attribute to set almost everything you need.  You could also create a single attribute to encapsulate all of the possible string combinations instead of having multiple attributes on each property.

All in all, I am loving code first and having attributes to control database generation instead of using the fluent API is huge and saves me a great deal of time.

posted on Monday, December 20, 2010 10:00 AM

This article is part of the GWB Archives. Original Author: Dane Morgridge

Related Posts