WPF - NotMapped аннотация в EF6 не хранит / сохраняет значения свойств

Question

Когда я пытаюсь вставить или обновить данные в моей таблице данных WPF usercontrol, данные не сохраняются в соответствующем свойстве.Это вызвано (по крайней мере, так я полагаю) моим связанным свойством, имеющим атрибут [NotMapped], все остальные свойства без аннотации работают правильно.

Данные, которые необходимо обновить, находятся внутри DataGrid компонент, который связан с ObservableCollection соответствующей моделью.Внутри модели есть несколько свойств с аннотацией [NotMapped], эти свойства должны быть исключены при создании таблицы (модели) в моей базе данных, хотя они мне нужны для привязки ввода, поэтому использование аннотации [NotMapped],

Поскольку данные привязаны к ObservableCollection, я не могу напрямую добавить свойства [NotMapped] к usercontrol (поэтому они не будут частью модели).

Ниже приведен пример:

Часть XAML На изображении ниже мы видим 1 свойство (pBreedte), которое равно 1 изNotMapped свойства, а также itemsource из datagrid:

Код UserControl позади (часть)

Часть модели, которая используется в ObservableCollection

Модель используется для EF6 (сначала код).

Есть ли способ сохранить / сохранить значения свойств NotMapped?Проще всего было бы просто включить NotMapped свойства в базу данных (поэтому удаление аннотации полностью), но я пытаюсь этого избежать.

Дополнительная справочная информация

Значения NotMapped добавляются, поскольку они функционируют как свойство заполнителя.Первоначально у меня было несколько decimal свойств, связанных непосредственно с datagrid, но текстовые поля не могут очень хорошо обрабатывать десятичные значения ( Правило проверки WPF, предотвращающее десятичный ввод в текстовое поле? ).Поэтому я создал строковый заполнитель для этих десятичных свойств, когда при сохранении формы десятичные свойства устанавливаются в соответствии с их аналогами.Таким образом, пользователь может добавлять десятичные знаки без необходимости использовать delay, value converter или что-либо еще.

Answer 1

Если вам не нужна эта информация в вашей базе данных, не храните ее - это значит, что ваш подход хорош.

Я думаю, что здесь может быть проблема в том, что вы используете свою модель сущности / базы данных в качестве модели пользовательского интерфейса.

Я бы посоветовал вам попытаться представить другую модель для элементов управления пользовательского интерфейса и пользовательского ввода. В начале модели могут показаться дублирующимися, но пока вы работаете над приложением, они начнут различаться, но описания одних и тех же элементов просто формируют разные перспективы.

Пример:

Модель сущности имеет класс CarEntity. Это чистый класс POCO, имеющий только необходимые свойства, которые будут содержать данные в соответствующей таблице.

Модель Ui имеет класс CarUi. Он имеет те же свойства, что и CarEntity. Они загружаются и отображаются из базы данных (из CarEntity), показанной пользователю. Если пользователь что-то меняет, значения diff отображаются из CarUi в CarEntity и затем сохраняются в DB.

При таком подходе разделения моделей вы не должны сталкиваться с проблемой, когда одно ограничение (пометить столбец, который не следует хранить в таблице) влияет на другие функции.

Надеюсь, это поможет, Приветствия и счастливое кодирование