How does Entity Framework handle Complex types?

Question

I am creating a Xamarin.Forms application that will be able to target multiple devices. In order to store data/preferences/etc I have to use SQLite.Net . As per documentation, and other users running into the issue, you can't use complex types as follows.

public class UserPreferences
{
    [PrimaryKey, AutoIncrement]
        public int ID { get; set; } /// great
        [MaxLength(50)]
        public string email { get; set; } /// strings are okay
        public byte[] byteArray {get; set;} ///storing blobs is fine
        ///... not okay below, because SQLite can't store complex types. I'm
        ///pretty sure even a List<string> isn't possible
        public List<Orders> favorites {get; set;}
}

This app will need to talk to a server as well. I understand the limitations on the client side, which means I will use Serialization/Deserialization and essentially blob storage with SQLite .

However, I got to thinking about the different options, either keep using SQLite.net , or use Entity on the serverside. I couldn't find any background information, on how Entity handles Complex Types, this is all I could find about how to use them. https://msdn.microsoft.com/en-us/data/jj680147.aspx

If I already have the logic for Serialization of the byte[] on the client-side, it would make my job easier.

Essentially, what I'm asking is, how does Entity handle storing/accessing the Complex Types ? I will use this answer to deduce if I want my application(which will require thousands of transactions a second) to use sqlite.net or use Entity

Answer 1

You're right, SQLite doesn't store complex types on an entity, but neither does EF. It is two separate entities. So, just make another entity Orders . SQLite also doesn't handle relationships or navigation properties. If you do want the foreignkey relationships handled automatically, check out https://bitbucket.org/twincoders/sqlite-net-extensions . It works pretty well as long as you configure the relationship correctly.