2015-03-07 1 views
1

Я собираюсь создать несколько таблиц с Entity Framework и с кодовым подходом. Однако некоторые из моих классов имеют сложные свойства, такие как:Возможно ли с помощью Entity Framework (de) сериализовать свойство объекта от/до строки?

public class Car 
{ 
    public ComplexDate DateBought { get; set; } 
} 

где ComplexDate является:

public class ComplexDate 
{ 
    public int? Year { get; set; } // Notice the optional Year. 
    public string Month { get; set; } 
    public int Day { get; set; } 
} 

и может анализировать значения, как 27AUG или 27AUG15

Могу ли я каким-то образом настроить мой Car или ComplexDate так, что Я могу сериализовать его в string или десериализовать обратно с string? Я хотел бы иметь столбец в базе данных под названием DateBought, но в коде я хотел бы использовать ComplexDate для него типа и быть в состоянии разобрать значение, хранящееся в базе данных #

. ВАЖНО:

I имеют несколько других сложных свойств, которые не являются датами, но являются parsable, которые я хотел бы хранить как строки, а также в еще не таблицах/столбцах. Это переоценило бы базу данных. Думаю, мне это не нужно.


UPDATE:

Вот еще один пример того, что я имею в виду:

public class Car 
{ 
    public CarColor Color { get; set; } 
} 


public class CarColor 
{ 
    private string _value; 

    // ...more code (ctr, parse etc.) 

    public override string ToString() 
    { 
     return _value; 
    } 
} 

Теперь я хотел бы иметь Car -стол с колонкой именем Color что бы автоматически (по некоторым магия) превращаются в CarColor в код ... Есть ли способ? Создание свойства Color (и других) a string разрушает весь проект моего приложения, потому что каждое свойство является сложным, потому что оно имеет некоторую логику для синтаксического анализа, допустимых значений и т. Д. Я бы хотел, чтобы он был последовательным (все сложно type) вместо смешивания строк и классов и других типов.

+0

Что вы в итоге сделали? –

+0

@Arash: Я сдал и создал другую модель для базы данных и конвертер, который переводит объекты из одной модели в другую. Это был способ много работать и сделало мои модели ненужными сложными только для работы EF. Итак, теперь у меня есть отдельные модели для базы данных и разные модели для приложения. – t3chb0t

ответ

0

IMHO вы, вероятно, хотите, чтобы свойство EF было DateTime и просто выполняло преобразование в пользовательском интерфейсе. Таким образом, вы можете привязываться к соответствующему столбцу даты базы данных и иметь возможность выполнять все сортировки и запросы, которые были бы невозможны, если вы используете ваш подход.

+0

Причина, по которой я не могу использовать _normal_ 'DateTime', состоит в том, что' Year' является необязательным. См. 'Int?' Рядом с 'Year'. Я постараюсь сделать это более ясным в моем вопросе. У меня есть и другие сложные свойства, которые не являются датами. – t3chb0t

0

Вы можете хранить поля даты отдельно.

Один на год (с ограничениями), один на месяц, один на день.

Таким образом, вы можете сортировать, группировать и т. Д. Из базы данных и использовать значения в своем классе для объединения и отображения по своему усмотрению.

+0

Это не только специальный класс даты ... У меня есть и другие сложные свойства.Я не хочу разбивать их на 80 столбцов;] – t3chb0t

+0

Привет, t3chb0t, это будет какой-то проект, в котором было 80 вещей, хранящихся в виде одного элемента в таблице базы данных. Хранение и манипуляция - это две разные вещи. Храните данные, которые необходимо сохранить, а затем свойства (NotMapped), которые управляют данными так, как вы хотите отобразить их клиенту. Маркировка их как NotMapped запрещает EF создавать столбцы для элементов в базе данных. EF достаточно умен, чтобы создавать таблицы, типы данных и отношения из классов, которые вы поставляете в своей модели, просто отметьте, что вы хотите не включить EF. –

Смежные вопросы