2014-10-16 1 views
1

Есть ли способ, которым я могу сказать EF, чтобы преобразовать мои свойства MultilingualString в строку перед отправкой их в базу данных (и наоборот при извлечении из базы данных)? Я хочу обернуть поведение, чтобы повторно использовать его.Сделать EF преобразовывать свойства строки с литой строкой в ​​строку перед отправкой в ​​базу данных

public class MyEntity 
{ 
    // I want this property to be considered a string by EF (it is castable to string) 
    public MultilingualString MyProperty { get; set; } 
} 

public class MultilingualString 
{ 
    public static implicit operator string(MultilingualString mlString) 
    { 
     return mlString.ToJson(); 
    } 

    public static explicit operator MultilingualString(string json) 
    { 
     return new MultilingualString(json); 
    } 

    ... 
} 
+0

Один из вариантов заключается в том, чтобы ваш 'MyProperty' был' [NotMapped] 'и имел свойство backing типа' string', которое отображается (MyProperty получит/установит его значение для свойства backing). Надеюсь, это не лучший ответ, так что оставим его как комментарий на данный момент. –

+0

Это именно то, что я делаю повсюду прямо сейчас ... Не нравится, и именно поэтому я прошу ... Спасибо в любом случае: P – billy

ответ

1

Три мысли:

Одна из них, чтобы сгенерировать классы из шаблона T4, который будет генерировать поле подкладочный и [NotMapped] MultilingualString. Технически вы будете писать меньше кода, и каждый шаблон T4 может использовать метод, который вы вводите с другой сборки, чтобы не повторять код генерации в каждом шаблоне. Я признаю, что эта идея не заставит вас чувствовать себя лучше.

Мысль две состоит в том, чтобы использовать PostSharp, присваивать свои поля поддержки и иметь расширение PostSharp, создавать многоязычные поля или наоборот. Большой недостаток этого заключается в том, что инструменты статического анализа не очень понравятся.

Мысль три состоит в том, чтобы сделать MultilingualString a ComplexType, который содержит поле строки как общедоступное свойство, а также имеет любые другие методы, которые вы создали для выполнения класса в настоящий момент. Он будет генерировать более грязное имя столбца базы данных, если вам это интересно.

I reckon 3 имеет наибольшую ценность.

EDIT:

Для варианта 3 вы можете контролировать имена столбцов, если вам нужно:

modelBuilder.Entity<MyEntity>().Property(x => x.MyProperty.StringValue) 
    .HasColumnName("i_dba_aprvd_rdbl_col_nm") 

Там нет причин, это свободно конфигурация не может быть сгенерирован с помощью отражения, чтобы найти все такое комплексное свойство если существует правило, с помощью которого можно определить имя столбца, например это было имя свойства типа MultilingualString для объекта.

+0

Спасибо! Я бы определенно использовал вариант 3 уже, если бы не то, что я не могу изменять имена столбцов базы данных, для обратной совместимости. – billy

+0

См. Мой EDIT для предложения о том, как изменить имена столбцов. Но даже если вы не изменяли имена столбцов таким образом, вы можете изменить создаваемую им миграцию, чтобы использовать RenameColumn, а не пары DropColumn и CreateColumn, которые она создаст для вас. –

+0

Да ... Я надеялся, что смогу повторно использовать атрибут Column в моей первой модели кода ... Может быть, пользовательский атрибут? – billy

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