c# - WPF MVVM: INPC and mediating communication between view model & model -
i've read various approaches communicating changes in model data view model. suggest model should implement inotifypropertychanged possible, may notify view model of changed properties. suggest service layer between model , view model, service layer implementing inpc, method calls being routed through service layer model service layer notifies view model.
i consider latter more granular revision of former , have begun implementing inpc in model classes. feels wrong because
a) have write event handler in view model notifications model. takes form of long switch(propertyname) sets corresponding property(s) on view model causing npc sent upwards again. feel i'm writing lot of boiler plate code here.
b) view model coupled model via bunch of strings regulated solely convention i.e no 'interface' defined. not mention difficulty causes ides.
c) model has modified accomodate context! if closed reason? thought patterns designed increase code reusability & seperation of concerns. not code required fire inpc events tedious , repetetive , not abstractable.
i'm keen know how wpf pros approach problem whether dependency properties etc. feeling missing something. i'm not keen on using framework learn 'from ground up'. i've been away wpf year or 2 , working angularjs has made me question methods here.
thanks!
for purpose of answer, call business object classes 'data types'.
in personal experience, view models always tied data types. have have properties of types want display, there reference view models namespace data types namespace.
what call model (from description in comment) sounds view models. view models have properties, of type of various data type classes, , methods, whereas data type classes hold properties part... they're holders of data , reporters of changes really.
you seem under impression inotifypropertychanged
interface performs duties between 'model' call , view model classes... in opinion, optional @ best... inotifypropertychanged interface page @ msdn:
the inotifypropertychanged interface used notify clients, typically binding clients, property value has changed.
therefore, see inotifypropertychanged
interface being 'life-blood' goes between views , view models , data objects. developers prefer 'wrap' each data type in own view model, prefer implement inotifypropertychanged
interface in data types directly.
the main reason can hook framework in custom collection classes have. enables me have collections aware of changes made property in item in collection among other things. enables me build data synchronisation base classes, objects know when have changes.
it saves time in creating matching view model classes each data type class. why have 2 classes 1 can do? i've never needed level of separation. if understand correctly, implementing interface in data type classes negate need perform point a).
some of points b) , c) may rendered invalid if can use .net 4.5 there new callermembernameattribute
attribute can use automatically feed name of each property propertychanged
handler. found article called c# 5–making inotifypropertychanged easier description it.
i've written several large scale wpf applications , few frameworks , i've never had problem implementing inotifypropertychanged
interface in data type classes. in fact, don't think have written them in same time if had implement wrapper view model classes each data type class. method has served me far , i'm planning on sticking it, until find better way @ least. 1 developer's opinion , have go feels right you.
Comments
Post a Comment