Question

I am working with Entity Framework Code first. I have a simple model:

public class Variable
{
    public string Name { get; set; }

    public int Id { get; set; }

    public IList<string> TextOptions
    {
        get;
        set;
    }
}

I ran into issues with the Property TextOptions being of type List<String>.

When I try to do this in Entity Framework, it does not map.

I found a solution on here (stackoverflow) that fixes my issue. I basically rework my class so that it takes the list and makes it a delimited string which gets persisted instead:

public class Variable : IVariable
{
    public string Name { get; set; }

    public int Id { get; set; }

    public virtual IList<string> TextOptions
    {
        get
        {

            return _TextOptions;

        }
        set
        {
            _TextOptions = value;
        }
    }

    private IList<string> _TextOptions;

    public string TextOptionsSerialized
    {
        get
        {
            return String.Join(";", _TextOptions);
        }
        set
        {
            _TextOptions = value.Split(new char[]{';'}, StringSplitOptions.RemoveEmptyEntries).ToList();
        }
    }
}

This code works fine. The problem that I have with it is that I think that it violates Separation of Concern. I don’t think my model class should be concerned with serializing a list of strings so that Entity framework can persist it.

I ran into a similar issue working in ASP.Net MVC. I had a post sent from the client that would be mapped to a model. There were some issues with the way the model was structured compared to the post. In MVC I could write a Custom Model Binder to handle the conversion in a very safe and reusable fashion.

Is there ANY way I can do this for Entity Framework that is as clean as Custom Model Binders are for MVC?

Answer 1

No, EF doesn’t have any type converters or custom type mappers as alternative to model binders from MVC. You must always use some hack to force persistence. Another way to do the same is mapping TextOptions as collection of related entities. It will make your separation of concerns better but it will complicate your model and working with Variable.

public class Variable
{
    public string Name { get; set; }

    public int Id { get; set; }

    public IList<TextOption> TextOptions
    {
        get;
        set;
    }
}

public class TextOption
{
    public int Id { get; set; }
    public string Text { get; set; }
}