Я перекодирую приложение WinForms (MySQL / EF6 с множеством полей для обновления) с использованием WPF. Я изучаю код, необходимый для поддержки INotifyPropertyChanged для каждого поля, и задаюсь вопросом, является ли это преимуществом перед классическим кодом при обработке событий.
Я разработал надежное приложение WinForms на C #, поддерживающее довольно сложную модель данных, включая EF6 / MySQL. Как вы можете себе представить, со многими текстовыми полями, полями со списком, NumUpDowns и т. Д., Есть много обработчиков событий для всех различных полей. Когда я смотрю на перемещение этой кодовой базы в WPF и ее собственную привязку данных, я неоднократно читал о необходимости перекодировать ваши объекты данных среднего уровня для поддержки INotifyPropertyChanged в установщиках для каждого поля в вашем классе.
Я уже кодировал как методы настройки экрана, так и обработчики событий Winforms, которые выполняют возможность двунаправленного обновления между классами и элементами управления. Конечно, это потребует некоторой модификации для адаптации к методам и свойствам управления WPF. Я пытаюсь решить, стоит ли усилий по написанию кода и текущего обслуживания, необходимых для настройки INotifyPropertyChanged для каждого отдельного поля, взаимодействующего с экраном, или просто для изменения более классического кода за обработчиками событий. У меня есть от 50 до 100 полей (разных типов), каждое из которых требует специального кодирования для двунаправленной привязки.
Стоит ли это того, или я что-то упустил как нуб WPF?
У меня есть много полей в существующих классах обслуживания данных, которые принимают эту форму:
public class clsLot
{
// Code omitted for general error codes, enums etc.
// Here are a long list of fields which are generated by EF6 model, decorated with straightforward {get; set; }
public long idLot { get; set; }
public string LotID { get; set; }
public Nullable<long> idRecipe { get; set; }
public string PlantOrder { get; set; }
public Nullable<System.DateTime> CreateDate { get; set; }
public string Inspector { get; set; }
public string LotType { get; set; }
[... Long list omitted. For ease of maintenance when new fields are added to the database and ef6 model regened, this list is copied from ef6 gened code
// maintenance methods omitted for mapping between this class and database (save, update etc.
}
Когда я вижу примеры двухстороннего связывания WPF, они говорят, что класс должен поддерживать INotifyPropertyChanged, и что каждое поле должно быть преобразовано
от более простой «публичной строки LotID {get; set;}» к чему-то вроде для каждого поля
public class User : INotifyPropertyChanged
{
// Begin modification for each field in the class that needs to be bi-directionally mapped
private string _LotID;
public string LotID
{
get { return this._LotID; }
set
{
if(this.name != value)
{
this._LotID = value;
this.NotifyPropertyChanged("LotID");
}
}
}
// End of modification for each field
public event PropertyChangedEventHandler PropertyChanged;
public void NotifyPropertyChanged(string propName)
{
if(this.PropertyChanged != null)
this.PropertyChanged(this, new PropertyChangedEventArgs(propName));
}
}
У меня нет проблем с добавлением открытого события и метода NotifyPropertyChanged к существующим классам.
Моя проблема заключается в 13-кратном расширении строк кода для поддержки INotifyPropertyChanged для каждого поля
из которых у меня есть от 50 до 100 полей (и я больше не могу копировать / вставлять из созданных автогенированных классов
по модели Ef6).
Стоит ли это того, чтобы просто перемещать и настраивать существующие методы настройки экрана и управления событиями, которые есть в приложении Winforms?
Суть моей проблемы заключается в том, что я работаю с автоматически сгенерированным кодом, использующим преимущества синтаксиса "public string LotID {get; set;}", который необходимо разбить на отдельные частные поля и открытые свойства для каждого поле / свойство, которое в настоящее время автоматически сгенерировано.