It turns out there are several ways to interact with the model. And use a direct connection to the model, as in this example:class BookViewModel : ViewModelBase
{
public Book Book;
public BookViewModel(Book book)
{
this.Book = book;
}
public string Title
{
get { return Book.Title; }
set
{
Book.Title = value;
OnPropertyChanged("Title");
}
}
}
In this case, however, VM will not be the flexible part of its role in serious applications. In any case, such a is a way, but rather where the model and logic are combined or have the same structure.If, however, the model is to be updated at the time of the change of information in VM immediately (which may be required in any system), it is necessary to use the Events to track VM changes and record M data. Unfortunately, I did not find an example.However, my task was that a VM change could be made to M at any time, and it was not important to do so immediately (Event) or during the team (e.g. retention).For this purpose, the VM code has been supplemented by methods GetModel:class JournalViewModel : PropertyChangedNotification,IJournal<CommonViewModel,ExcavationViewModel>
{
public CommonViewModel CommonInfo
{
get { return GetValue(() => CommonInfo); }
set { SetValue(() => CommonInfo, value); }
}
public ObservableCollection<ExcavationViewModel> Excavations
{
get { return GetValue(() => Excavations); }
set { SetValue(() => Excavations, value); }
}
public JournalViewModel(Journal journal)
{
CommonInfo = new CommonViewModel(journal.CommonInfo);
Excavations = new ObservableCollection<ExcavationViewModel>();
foreach (var excavation in journal.Excavations)
{
Excavations.Add(new ExcavationViewModel(excavation));
}
}
public Journal GetModel()
{
ObservableCollection<Excavation> excavations = null;
if(Excavations!=null)
{
excavations = new ObservableCollection<Excavation>();
foreach(var excavation in Excavations)
excavations.Add(excavation.GetModel())
}
return new Common
{
Excavations= excavations ,
CommonInfo = CommonInfo.GetModel()
};
}
}
class CommonViewModel : PropertyChangedNotification,ICommon
{
public String Object
{
get { return GetValue(() => Object ); }
set { SetValue(() => Object , value); }
}
public UInt32 NumJournal
{
get { return GetValue(() => NumJournal ); }
set { SetValue(() => NumJournal , value); }
}
public CommonViewModel(Common common)
{
Object = common.Object;
NumJournal = common.NumJournal ;
}
public Common GetModel()
{
return new Common
{
Object = Object ,
NumJournal = NumJournal
};
}
}
class ExcavationViewModel : PropertyChangedNotification, IExcavation
{
public String NumExcavation
{
get { return GetValue(() => NumExcavation ); }
set { SetValue(() => NumExcavation , value); }
}
public DateTime DateCreateExcavation
{
get { return GetValue(() => DateCreateExcavation ); }
set { SetValue(() => DateCreateExcavation , value); }
}
public ExcavationViewModel(Excavation excavation)
{
NumExcavation = common.NumExcavation ;
DateCreateExcavation = common.DateCreateExcavation ;
}
public Excavation GetModel()
{
return new Excavation
{
NumExcavation = NumExcavation ,
DateCreateExcavation = DateCreateExcavation
};
}
}
If the people who read this answer have the opportunity to answer the question: How to update the Model at the time of the VM change, I would be very grateful. Having the idea of doing this through Event is good, but seeing the example is better.
I would also be grateful for the advice and comments on the method used (GetModel).EDIT 25.06.2015 Following the precise comments @VladD, I decided to make some changes, perhaps they would be more appropriate than the current implementation.
And it's true there's a lot of pros and cons everywhere. In my exercise, the user can work directly with a few magazines, suggesting from 10. Now I keep a collection not of 10 Journals (models) but of 10 JournalViewModel (hereinafter referred to as JourVM or simply VM), naturally JourVM contains many properties, fields, methods and teams, in which case I don't keep the data in the form of the Journal in memory.In this case, I'm kind of winning a little memory because I don't keep the Journal.Perhaps it would be better to keep a collection from the Journal (List) and, when the deposits are switched, use the interaction to use the model by extracting the data from the VM model, and to carry out the model objects through all VM for instant changes to the model, if the code described above is illustrated:class JournalViewModel : PropertyChangedNotification, IJournal<CommonViewModel, ExcavationViewModel>
{
public CommonViewModel CommonInfo
{
get { return GetValue(() => CommonInfo); }
set
{ SetValue(() => CommonInfo, value);}
}
public ObservableCollection<ExcavationViewModel> Excavations
{
get { return GetValue(() => Excavations); }
set { SetValue(() => Excavations, value); }
}
private Journal _JournalM;
public JournalViewModel(Journal journal)
{
_JournalM = journal;
CommonInfo = new CommonViewModel(_JournalM.CommonInfo);
Excavations = new ObservableCollection<ExcavationViewModel>();
foreach (var excavation in _JournalM.Excavations)
{
Excavations.Add(new ExcavationViewModel(excavation));
}
}
}
class CommonViewModel : PropertyChangedNotification, ICommon
{
public String Object
{
get { return GetValue(() => Object); }
set
{
SetValue(() => Object, value);
_CommonM.Object = Object;
}
}
public UInt32 NumJournal
{
get { return GetValue(() => NumJournal); }
set
{
SetValue(() => NumJournal, value);
_CommonM.NumJournal = NumJournal;
}
}
private CommonInfo _CommonM;
public CommonViewModel(Common common)
{
_CommonM = common;
Object = _CommonM.Object;
NumJournal = _CommonM.NumJournal;
}
}
class ExcavationViewModel : PropertyChangedNotification, IExcavation
{
public String NumExcavation
{
get { return GetValue(() => NumExcavation); }
set
{
SetValue(() => NumExcavation, value);
_ExcavationM.NumExcavation = NumExcavation;
}
}
public DateTime DateCreateExcavation
{
get { return GetValue(() => DateCreateExcavation); }
set
{
SetValue(() => DateCreateExcavation, value);
_ExcavationM.DateCreateExcavation = DateCreateExcavation;
}
}
private Excavation _ExcavationM;
public ExcavationViewModel(Excavation excavation)
{
_ExcavationM = excavation;
NumExcavation = _ExcavationM.NumExcavation;
DateCreateExcavation = _ExcavationM.DateCreateExcavation;
}
}
The VM designer is referring to M, we refer to it in VM, and we don't have precious memory, when changing information, it changes immediately in the right area of M and does not need to switch between VM.
My application is now being implemented through TabControl.(1) TabControl has the deposits of the Journal, the Contex and the DataContex have MainVM, which in turn keeps a VM with a collection of journals, a separate VM with construction and a VM with a check.(2) TabControl uses the collection journals (DataContex to the VM collection) stored another TabControl with links to certain parts of VM., causing some brakes in the schedule =(() If I still fail to interpret this information to me correctly to reflect on and correct the structure and logic of the application, it's very sad.
