Complex Type Serialization via FluentAPI

[ma3yta]

Is the way to define serialization/deserialization in OnModelCreating and leave only POCO class with one property public MyComplexType MyComplexType { get; set; } without attributes and additional property?

public class MyEntity
{
    //...
    [NotMapped]
    public MyComplexType MyComplexType { get; set; }

    public string MySerializedComplexType
    {
        get { return Serialize(MyComplexType); }
        set { MyComplexType = Deserialize(value); }
    }
    //...
}

Thanks

[divega]

@ma3yta Just to confirm, are you asking for the ability to register in the EF model the 2-way conversions from a string stored in a database column to a structured object instance?

If that is what your question is about, the answer is that we are not planning to do it for EF6, and maybe we will do it in the future for EF Core.

The following EF Core issues contain relevant discussions:
dotnet/efcore#240
dotnet/efcore#4021
dotnet/efcore#246

[ma3yta]

@divega yes. thanks

[ma3yta]

@divega Do you have plans to work on EF7 and implement those features http://enterprisecraftsmanship.com/2014/11/29/entity-framework-6-7-vs-nhibernate-4-ddd-perspective/ ?

[divega]

@ma3yta I only skimed over that article (which seems very good) and here is a summary:

• The mentioned "requirement" to use foreign key properties is not accurate: For EF Core you can have FKs in shadow state (meaning they are tracked by the DbContext but they don't appear in the objects). EF6 has alwas supported independent associations that don't have FKs, although they have limitations and we recommend having FK properties.
• EF Core already has some support for Hi/Lo an other value generators.
• AFAIR, the ability to map collection navigation properties to fields is not there. @ajcvickers may provide more inforation but I think this would be an easy gain to enable the kind of read-only collection pattern described in the article.

[ajcvickers]

@ma3yta @divega The current codebase (to be released as 1.1) supports using backing fields for navigation properties. However, we could probably improve the API surface. I'll file an issue on that.

Also, EF Core supports deleting orphans--point 1 in the post.

[ma3yta]

Very bad. We choose NHibernate for our project. But migrations is very good.