Uses Units.Net with Entity Framework

[surrealist]

I would like to use Units.Net in entity classes for Entity Framework. For example:

public class Box {
    public int Id { get; set; }
    public string Color { get; set; }
    public Length Width { get; set; }
    public Length Height { get; set; }
}

I found that EF ignored the Width and Height property (so I have only 2 columns left in the table) I don't sure that because of Length is struct or not.

Id	Color
1	Yellow
2	Orange

It could be possible if in this case Length is a ComplexType class then it will be created with multiple embedded columns in database table such as Width_Amount and Width_Unit.

Id	Color	Width_Amount	Width_Unit	Height_Amount	Height_Unit
1	Yellow	50	cm	90	cm
2	Orange	600	mm	120	mm

Please give me suggestion or your opinion on this.

[angularsen]

Without knowing your usecase, I would generally recommend you do not store complex types in your database. Instead store the double value of a known unit, I would recommend the default SI unit, such as Meter for Length and Kilogram for Mass. You can still keep the Units.NET properties around as wapper properties ignored by EF, to make it more convenient to use.

public class Box 
{
    public int Id { get; set; }
    public string Color { get; set; }

    // Wrapper property, ignored by EF
    [NotMapped]
    public Length Width 
    { 
         get { return Length.FromMeters(WidthMeters); } 
         set { WidthMeters = value.Meters; } 
    }

    [NotMapped]
    public Length Height
    { 
         get { return Length.FromMeters(HeightMeters); } 
         set { HeightMeters = value.Meters; } 
    }

    // These are stored in DB
    public double WidthMeters { get; set; }
    public double HeightMeters { get; set; }
}

NotMappedAttribute tells EF to ignore that property.

You can also use a ColumnAttribute to name the WidthMeters property to "Width" in the database if you so wish.

[surrealist]

Really thanks for your kindly answer and detailed example.

Anyway, I'm still considering to store the "unit" along with its "amount". I wonder that this might leads to better class modeling or not especially if I want to do it DDD way. I found useful class models in Quantity archetype pattern of the book Enterprise Patterns and MDA.

My expected benefits to store units along with the quantity's amount.

1. The data can be more self descriptive.
2. Able to mix several units in the same domain model.

For example, if a tile uses inches and another tiles use centimetres.
Why should I store in one single shared unit (ex. meters)?
How could I know how to represent that tile back to the user with its correct units?

Then, let's us consider to DateTimeOffset and DateTime. DateTimeOffset knows its own time zone and I'm trying to make Quantity knows its own unit.

I don't sure that if this align to the design philosophy or out of scope of the Units.Net library or not.

[angularsen]

I would probably store it like this:

public class Person {
    public double Height { get; set; } // 1.84
    public string HeightUnit { get; set; } // "LengthUnit.Meter" or "meter" or "m", whatever you think is robust enough and works
    public Length HeightWrapper { get { /* parse here */ } set { /* assign Height and HeightUnit */ }
}

You could also serialize public LengthUnit HeightUnit { get; set; } directly, but then you are trusting Units.NET to never break compatibility by not changing the numbers of the enumeration, and there is absolutely no guarantee of that not happening. In fact it is very likely to happen due to how we generate the source code. If you instead serialize as a string, then you have a better chance as we will strive to not break compatibility in our library on unit names, at least not without bumping major version number. You could also write your own enumeration for the units you care about, then you are in full control of it.

[surrealist]

I've got several useful ideas from you,
even it was not perfect match to my need.

Thanks. I'll close the issue.

[mivano]

Just for reference: when you are using EF 2.1, you can use value converters:

  var energyConverter = new ValueConverter<Energy, decimal>(
                v => Convert.ToDecimal(v.KilowattHours),
                v => Energy.FromKilowattHours(v));

            modelBuilder.Entity<EntitySummary>()
                .Property(l => l.ContractedCapacity)
                .HasConversion(energyConverter);

Here I store it as a decimal and implicitly as kWh. Of course you can store it in different ways, but no need for separate fields.

[surrealist]

Thanks to raise this issue again and show how the new EF Core 2.1 Value Conversion can help this three years ago question.

Nice for me to reconsider about it again.