text: when developing interactive applications , design considerations include separating an application &# 39 ; s data , presentation , and user input into specialized components . several different architecture patterns that are implementations of the observer pattern described above have evolved to address these considerations . the model view presenter ( mvp ) pattern is used mostly for building user interfaces ( uis ). in the mvp pattern the model is an interface defining the data to be displayed or otherwise acted upon in the user interface , the view is an interface that displays data from the model and routes user commands ( events ) to the presenter to act upon that data and the presenter acts upon the model and the view . the presenter retrieves data from repositories ( the model ), and formats it for display in the view . in the model view view - model ( mvvm ) pattern , the model can refer to either an object model that represents the real state content ( an object - oriented approach ), or the model can refer to a data access layer that represents that content ( a data - centric approach ). the view typically refers to all elements displayed by the including buttons , windows , graphics , and other controls . the view - model is a model of the view meaning it is an abstraction of the view that also serves in data binding between the view and the model . the view - model exposes public properties , commands , and abstractions . binding in user interfaces of applications is commonly used to synchronize state between the view ( which displays the data and with which the user can interact ) and the model ( which holds the current state of the data ). the result of binding typically applies changes made in the view to the model . changes in the model are not directly assigned to the view . instead , to apply changes made in the model to the view , the model fires a change event that is caught by the view . the view requests the new value stored in the model and the new value is applied to the view . in some design patterns ( like mvvm or mvp ) the model and the view are not directly bound to each other . instead , the view is bound to a third object , the view - model ( or presenter ). the view - model passes the change data to the model . in one implementation of this pattern , the view - model can act as a proxy between the view and the model . one consequence of the view - model acting as a proxy is that events fired in the model do not reach the view . “ firing an event ” means to call all event handlers which are registered to that event . thus , when an event occurs in the model , the view - model has to fire an event of its own in order for the view to be updated with the event . one way to handle the need for the view - model to fire an event is for the view - model to catch the model &# 39 ; s event and for the view - model to fire an appropriate event as well . the event fired by the view - model can be caught by the view , the view can request an update from the view - model and the view - model can send an update to the view . this solution requires a considerable amount of coding for each view - model element to model element connection . coding can become complex , in particular when one element in the model affects more than one element in the view - model , tending to make this solution error prone . the subject matter described herein provides an example of an observer ( e . g ., a view ) that is registered to events in a subject ( e . g ., a model ) indirectly using a proxy ( e . g ., a view - model ). in accordance with aspects of the subject matter disclosed herein , a dependency informer can be created . the dependency informer can register to receive notifications of events in the first subject ( e . g ., the model ). a table in the dependency informer can define the set of connections between pairs of elements . one of the elements can be in the first subject ( e . g ., the model ) and its counterpart can be in the second subject ( e . g ., the view - model ). the dependency informer can map between an element name or element identifier in the first subject and an element name or element identifier in the second subject . the dependency informer can map between an element name or element identifier in one subject and another element name or element identifier in the same subject . the dependency information can map between an element name in the first subject and a delegate . the delegate can be a pointer to a method to be invoked . the set of definition mappings can be used by the dependency informer to select the correct action to take when receiving an event from the first subject . in response to detecting an event fired by the first subject , the dependency informer by default can fire a corresponding event in the second subject to notify the second observer ( e . g ., the view ) about the event . in response to detecting an event fired by the first subject , the event including one or more parameters , the dependency informer can execute customized code based on the value of the parameter . for example , a property change event with a parameter of “ property1 ” can mean that the “ property1 ” property was changed while the same event with a parameter of “ property2 ” can indicate that the “ property2 ” property was changed , etc .). the customized code can execute one of a number of potential code paths in response to the content of the parameters associated with the event received from the first subject . the dependency informer object created can optionally prioritize the order in which the delegates are invoked . the dependency informer can be implemented as a class with a method that can be invoked upon detection of an event ( e . g ., an “ onevent ” action ). for an event where the parameter of the event received from the first subject is some agreed - upon , specified or configured value ( e . g ., the value is empty or null ), the agreed - upon value may signify that all the elements are affected , and that therefore all the delegates will be invoked . similarly , an agreed - upon value may signify that the event refers to all possible parameter values . fig1 a illustrates an example of a system 100 that applies changes made to a model ( e . g . first subject ) to a view ( e . g . second observer ) using a dependency informer in accordance with aspects of the subject matter disclosed herein . all or portions of system 100 may reside on one or more computers such as the computers described below with respect to fig3 . system 100 may execute on a software development computer such as the software development computer described with respect to fig4 . system 100 or portions thereof may execute within an integrated development environment or ide or may execute outside of an ide . the ide can be an ide such as the one described with respect to fig4 or can be any other ide . all or portions of system 100 may be implemented as a plug - in or add - on . system 100 may include one or more computers or computing , devices such as a computer 102 comprising : one or more processors such as processor 143 , etc ., a memory such as memory 145 , and one or more program modules comprising a dependency informer such as dependency informer 116 , which when loaded into the memory 145 cause the processor 143 , etc . to execute the actions attributed to the dependency informer 116 . a process such as process 106 may execute on computer 102 . the process 106 may affect or may be affected by a model 108 that stores data on which the process 106 acts or on which the process 106 depends . system 100 may also include one or more view - models such as view - model 110 , etc . and one or more views of the model such as view 112 , etc . the model 108 can generate an event . the event ( e . g ., event 118 ) can be sent to the dependency informer 116 . the event can identify an element in the model to which the event relates . the event can identify particular semantics of the event to which the sent event refers . one or more parameters can be used to identify the element in the model to which the event relates . one or more parameters can be used to identify the semantic to which the event refers . an instance of the dependency informer 116 can be initialized in the view - model 110 . the instance of the dependency informer 116 can be initialized with a delegate to a method in the view - model 110 . the method in the view - model 110 can fire an event . dependency informer 116 may use this method in order to fire events in view - model 110 which are associated with a reference to the events such as event 118 that occurred in the instance of the model 108 . connections between elements in the model 108 and elements in the view - model 110 can be defined . alternatively , connections between elements in the model 108 and elements in the view - model 110 can be read from a configuration file by the dependency informer upon initialization or the connections between elements in the model 108 and elements in the view - model 110 can be read from a configuration file by an object that calls a series of add functions with the appropriate parameters . custom code behavior can also be configured . the custom code behavior can be invoked when one of the elements in the model 108 changes or when any event is fired by the model by creating a connection between an element in the model 108 and a delegate to a method which includes the custom code ( e . g ., custom code 121 ) or to an anonymous method which includes the custom code . an anonymous function is a function or subroutine that is defined or called without being bound to an identifier . the dependency informer 116 can be initialized with an input parameter comprising a reference to an inspected ( observed ) object ( i . e ., the first subject ). the inspected object can be any object that implements the interface with the referenced event . an input parameter can comprise a delegate to a method that fires an event in the containing object ( i . e ., the second subject including but not limited to a view - model such as view - model 110 that includes dependency informer 116 ). the dependency informer 116 can save the input parameters on initialization for later use . the dependency informer 116 can register to receive notifications whenever the event in the model 108 occurs . the dependency informer 116 can maintain a mapping such as but not limited to map 114 between an element name and a list of delegates . connections between the model ( i . e ., the first subject ) elements and delegates can be added to the map . connections can be forwarding connections . connections can be splitting connections . when a forwarding connection is added , the dependency informer 116 can create a new delegate which , when called , can invoke the on event delegate method with the element identifier . this new delegate can be added to the map using the splitting method logic . when the model fires event such as change event 118 , the dependency informer &# 39 ; s event handler can be invoked . the dependency informer &# 39 ; s event handler can check if the element identifier sent in the event exists in the map 114 . if it does , the event handler can invoke one or more of the delegates in the list of delegates mapped to the element identifier to generate one or more events such as event 119 , etc . if the event was fired with an agreed - upon , specified or configured value ( e . g ., an empty parameter ), all the delegates in the map can be invoked . fig1 b illustrates an example 120 of a use of a dependency informer in a system with a model 122 ( i . e ., first subject ), a view - model 128 ( i . e ., first observer and second subject ) and a view 142 ( i . e ., second observer ). in accordance with aspects of the subject matter described herein , the view 142 can have a pointer 144 to the view - model 128 . the view - model 128 can have a pointer 130 to the model 122 . suppose in the view there are text boxes or labels that display some or all of three numbers such as num2v 146 , num2v 148 and sumv 150 . suppose sumv 150 is the sum of num1v 146 and num2v 148 . suppose the text boxes or labels display the data stored in corresponding elements of the model 122 for the numbers num1v 146 and num2v 148 . suppose the same elements exist in the view - model 128 as num1vm 134 , num2vm 136 and sumvm 138 . suppose that in the model 122 only the corresponding element num1m 124 exists for num1vm 134 , and model element num2m 126 corresponds to num2vm 136 . suppose the sum is not included in the model 122 because calculation of the sum is done in the ui logic . in the example , num1v 146 can be bound to num1vm 134 and num2v 148 can be bound to num2vm 136 . the value of num1m 124 can be returned to num1v 146 and the value of num2m 126 to num2v 148 . whenever num1m 124 changes , the change can be reflected in num1v 146 . whenever num2m 126 changes , the change can be reflected in num2v 148 . whenever either num1m 124 or num2m 126 changes , the change can be reflected in sumv 150 . in accordance with aspects of the subject matter disclosed herein , changes in model elements can be reflected in values displayed in the view because the dependency informer 132 includes an change event handler that is invoked whenever the model 122 fires a change event . the change event handler can receive the element identifier of the model element that has changed allowing the dependency informer 132 to use the on change method 140 to fire a change event in the view model 128 with an appropriate element identifier . to define the connections between the view - model 128 and the model 122 , the dependency informer 132 can be informed of dependencies that exist between elements in the view - model 128 and the model 122 . the dependency information comprises the mapping information . for example , dependency informer 132 can be told that num1vm 134 is dependent on num1m 124 and that num2vm 136 is dependent on num2m 126 . the dependency informer 132 can also be told that sumvm 138 is dependent on num1m 124 and num2m 126 . thus if num1m 124 changes , the model 122 can fire a change event identifying num1m 124 as the element that changed . the dependency informer 132 can catch that change event , and can access the map information . the map information will indicate that there are two elements that depend on num1m 124 : num1vm 134 and sumvm 138 . dependency informer 132 can use the on change event 140 to which dependency informer 132 delegates , to inform the view - model 110 that the values for num1vm 134 and sumvm 138 have changed . the dependency informer 132 can call on change event 140 with num1vm 134 and sumvm 138 a . change event can also be fired in the view - model 128 for num1vm 134 and sumvm 138 . these change events can be caught by the view 142 . the view 142 can see that num1m 134 and sumvm 138 have been updated . in response the view 142 can determine the updated values by asking the view - model 128 for num1vm 134 and the view - model 128 can return the value which it got from the model 122 for num1m 124 . for sumv 150 the view - model 128 can be asked for sumvm 138 . the view - model 128 can return the sum of num1m 124 and num2m 126 . alternatively , a second method ( in addition to the on - change method 140 ) can be called to compute the sum of num1vm 134 and num2vm 136 . fig1 e illustrates an example 170 of a dependency informer 152 and an interface ( e . g ., inotifyevent 164 ). a dependency informer 152 can include a delegate to an on event method 154 , an event handler 156 and a map 158 . the map 158 can include information including the element name and a list of delegates . the dependency informer 152 can also include one or more add methods ( e . g ., method 160 and method 162 ) having parameters comprising a string and a string or comprising a string and a delegate . the dependency informer 152 can have a pointer to the object that has the on event method in it . for example , in fig1 b , dependency informer 132 has the pointer to the on change method 140 inside view - model 128 . the dependency informer 152 of fig1 c can also have an event handler such as event handler 156 . the event handler 156 can register for the event 166 of the inotifyevent interface 164 . inotifyevent interface 164 in this example is an interface that declares the event . to register to receive notifications when events occur , the object can implement this interface . in the example , the model implements the inotifyevent interface 164 with the event 166 event . the dependency informer 152 is given the pointer to the model which implements inotifyevent interface 164 . since model 122 implements interface 164 , the dependency informer 152 can register event handler 156 to the model &# 39 ; s event by using event 166 defined in the inotifyevent interface 164 . the dependency informer 152 can then register for the events fired by the model . by registering , the dependency informer 152 will be told to call the event handler 156 whenever the event fires . the dependency informer 152 also includes the map 158 which has the element identifier and a list of delegates . the map holds the definitions of dependencies described above between the objects . in fig1 b , the dependencies defined included : num1vm 134 is dependent on num1m 124 , and sumvm 138 is dependent on num1m 124 . the second parameter is a list of delegates . because num1vm 134 ( b ) depends on num1m 124 ( a ), a delegate which calls the on change event 140 for num1vm 134 can be added into the list for the key num1m 124 . whenever num1m 124 fires a change event , a change event in view model 128 can be fired with num1vm 134 as the parameter . similarly , when the connection between num1m 128 and sumvm 138 is defined , the dependency informer 132 can check the map for a key of num1m 124 . if a key of num1m 124 is found , the list of delegates can be retrieved and the delegate related to sumvm 138 can be added to the list of delegates . if the key of num1m is not found , a new list of delegates can be created and the delegate related to sumvm 138 can be added to the new list of delegates . dependency informer 152 may include two add methods , one which gets two strings , add method 160 and one which gets a string and a delegate , add method 162 . add method 162 gets a string and a delegate . the string reflects the identifier of an event parameter in the first subject ( e . g . element in the model ) and the delegate reflects an action or actions to be taken . for example , suppose num1m 124 changes , and the action to be taken is to change the background color by calling a method called changebackgroundcolor . add method 162 can be called with num1m 124 as the first parameter and a pointer to the changebackgroundcolor method as the second parameter . the dependency informer can go to the map , and search for a key of num1m 124 in the map . if the key of num1m 124 is found in the map , the list of delegates can be retrieved and the delegate ( the pointer to the changebackgroundcolor method ) can be added to the list of delegates . in the second add method , method 160 , the same logic can execute except that instead of having a delegate , the add method would have an event parameter in the second object ( e . g . view - model &# 39 ; s element identifier ) as the second parameter . a new delegate can be created . the action of the new delegate can be to call on event ( e . g ., onevent 154 ) created in the first field with the second string as the parameter . change event handler can handle the firing of the change event . the change event can be formed with the element name as a parameter . the change event handler can receive the element name and search the map for a key with this element name . if there is no key with the element name , nothing else has to be done . if the key with the element name is found , each delegate in the list of delegates can be called , invoking whatever method the delegate in the list calls . fig2 illustrates a method 200 that can use a dependency informer to apply changes made to a model to a view in accordance with aspects of the subject matter disclosed herein . the method described in fig2 can be practiced by a system such as but not limited to the one described with respect to fig1 a and for which examples were provided in fig1 b and 1 c . while method 200 describes a series of acts that are performed in a sequence , it is to be understood that method 200 is not limited by the order of the sequence . for instance , some acts may occur in a different order than that described . in addition , an act may occur concurrently with another act . in some instances , not all acts may be performed . at 202 a map , as described more fully above , can be received . the dependency informer can register for the event in the first subject ( e . g . model ) at 203 . at 204 an event fired by a first subject can be received by the dependency informer . the event can identify different semantics of the event by using a parameter . at 206 the dependency informer &# 39 ; s event handler can be invoked . at 208 the dependency informer can access its map to determine what delegates need to be invoked . at 210 the dependency map can be searched for a key matching the parameter sent by the event . at 212 if the key is found , each delegate in the list can be invoked at 216 . at 214 if the key is not found in the map the process can end . in order to provide context for various aspects of the subject matter disclosed herein , fig3 and the following discussion are intended to provide a brief general description of a suitable computing environment 510 in which various embodiments of the subject matter disclosed herein may be implemented . while the subject matter disclosed herein is described in the general context of computer - executable instructions , such as program modules , executed by one or more computers or other computing devices , those skilled in the art will recognize that portions of the subject matter disclosed herein can also be implemented in combination with other program modules and / or a combination of hardware and software . generally , program modules include routines , programs , objects , physical artifacts , data structures , etc . that perform particular tasks or implement particular data types . typically , the functionality of the program modules may be combined or distributed as desired in various embodiments . the computing environment 510 is only one example of a suitable operating environment and is not intended to limit the scope of use or functionality of the subject matter disclosed herein . with reference to fig3 , a computing device in the form of a computer 512 is described . computer 512 may include at least one processing unit 514 , a system memory 516 , and a system bus 518 . the at least one processing unit 514 can execute instructions that are stored in a memory such as but not limited to system memory 516 . the processing unit 514 can be any of various available processors . for example , the processing unit 514 can be a gpu . the instructions can be instructions for implementing functionality carried out by one or more components or modules discussed above or instructions for implementing one or more of the methods described above . dual microprocessors and other multiprocessor architectures also can be employed as the processing unit 514 . the computer 512 may be used in a system that supports rendering graphics on a display screen . in another example , at least a portion of the computing device can be used in a system that comprises a graphical processing unit . the system memory 516 may include volatile memory 520 and nonvolatile memory 522 . nonvolatile memory 522 can include read only memory ( rom ), programmable rom ( prom ), electrically programmable rom ( eprom ) or flash memory . volatile memory 520 may include random access memory ( ram ) which may act as external cache memory . the system bus 518 couples system physical artifacts including the system memory 516 to the processing unit 514 . the system bus 518 can be any of several types including a memory bus , memory controller , peripheral bus , external bus , or local bus and may use any variety of available bus architectures . computer 512 may include a data store accessible by the processing unit 514 by way of the system bus 518 . the data store may include executable instructions , 3d models , materials , textures and so on for graphics rendering . computer 512 typically includes a variety of computer readable media such as volatile and nonvolatile media , removable and non - removable media . computer storage media may be implemented in any method or technology for storage of information such as computer readable instructions , data structures , program modules or other data . computer storage media includes , but is not limited to , ram , rom , eeprom , flash memory or other memory technology , cdrom , digital versatile disks ( dvd ) or other optical disk storage , magnetic cassettes , magnetic tape , magnetic disk storage or other magnetic storage devices , or any other transitory or non - transitory medium which can be used to store the desired information and which can be accessed by computer 512 . it will be appreciated that fig3 describes software that can act as an intermediary between users and computer resources . this software may include an operating system 528 which can be stored on disk storage 524 , and which can allocate resources of the computer 512 . disk storage 524 may be a hard disk drive connected to the system bus 518 through a non - removable memory interface such as interface 526 . system applications 530 take advantage of the management of resources by operating system 528 through program modules 532 and program data 534 stored either in system memory 516 or on disk storage 524 . it will be appreciated that computers can be implemented with various operating systems or combinations of operating systems . a user can enter commands or information into the computer 512 through an input device ( s ) 536 . input devices 536 include but are not limited to a pointing device such as a mouse , trackball , stylus , touch pad , keyboard , microphone , and the like . these and other input devices connect to the processing unit 514 through the system bus 518 via interface port ( s ) 538 . an interface port ( s ) 538 may represent a serial port , parallel port , universal serial bus ( usb ) and the like . output devices ( s ) 540 may use the same type of ports as do the input devices . output adapter 542 is provided to illustrate that there are some output devices 540 like monitors , speakers and printers that require particular adapters . output adapters 542 include but are not limited to video and sound cards that provide a connection between the output device 540 and the system bus 518 . other devices and / or systems or devices such as remote computer ( s ) 544 may provide both input and output capabilities . computer 512 can operate in a networked environment using logical connections to one or more remote computers , such as a remote computer ( s ) 544 . the remote computer 544 can be a personal computer , a server , a router , a network pc , a peer device or other common network node , and typically includes many or all of the elements described above relative to the computer 512 , although only a memory storage device 546 has been illustrated in fig3 . remote computer ( s ) 544 can be logically connected via communication connection ( s ) 550 . network interface 548 encompasses communication networks such as local area networks ( lans ) and wide area networks ( wans ) but may also include other networks . communication connection ( s ) 550 refers to the hardware / software employed to connect the network interface 548 to the bus 518 . communication connection ( s ) 550 may be internal to or external to computer 512 and include internal and external technologies such as modems ( telephone , cable , dsl and wireless and isdn adapters , ethernet cards and so on . it will be appreciated that the network connections shown are examples only and other means of establishing a communications link between the computers may be used . one of ordinary skill in the art can appreciate that a computer 512 or other client device can be deployed as part of a computer network . in this regard , the subject matter disclosed herein may pertain to any computer system having any number of memory or storage units , and any number of applications and processes occurring across any number of storage units or volumes . aspects of the subject matter disclosed herein may apply to an environment with server computers and client computers deployed in a network environment , having remote or local storage . aspects of the subject matter disclosed herein may also apply to a standalone computing device , having programming language functionality , interpretation and execution capabilities . fig4 illustrates an integrated development environment ( ide ) 600 and common language runtime environment 602 . an ide 600 may allow a user ( e . g ., developer , programmer , designer , coder , etc ) to design , code , compile , test , run , edit , debug or build a program , set of programs , web sites , web applications , and web services in a computer system . software programs can include source code ( component 610 ), created in one or more source code languages ( e . g ., visual basic , visual j #, c ++, c #, j #, java script , apl , cobol , pascal , eiffel , haskell , ml , oberon , perl , python , scheme , smalltalk and the like ), the ide 600 may provide a native code development environment or may provide a managed code development that runs on a virtual machine or may provide a combination thereof . the ide 600 may provide a managed code development environment using the . net framework . an intermediate language component 650 may be created from the source code component 610 and the native code component 611 using a language specific source compiler 620 using a modeling tool 652 and model store 653 and the native code component 611 ( e . g ., machine executable instructions ) is created from the intermediate language component 650 using the intermediate language compiler 660 ( e . g . just - in - time ( ht ) compiler ), when the application is executed . that is , when an il application is executed , it is compiled while being executed into the appropriate machine language for the platform it is being executed on , thereby making code portable across several platforms . alternatively , in other embodiments , programs may be compiled to native code machine language ( not shown ) appropriate for its intended platform . a user can create and / or edit the source code component according to known software programming techniques and the specific logical and syntactical rules associated with a particular source language via a user interface 640 and a source code editor 651 in the ide 600 . thereafter , the source code component 610 can be compiled via a source compiler 620 , whereby an intermediate language representation of the program may be created , such as assembly 630 . the assembly 630 may comprise the intermediate language component 650 and metadata 642 . application designs may be able to be validated before deployment . the various techniques described herein may be implemented in connection with hardware or software or , where appropriate , with a combination of both . thus , the methods and apparatus described herein , or certain aspects or portions thereof , may take the form of program code ( i . e ., instructions ) embodied in tangible media , such as floppy diskettes , cd - roms , hard drives , or any other machine - readable storage medium , wherein , when the program code is loaded into and executed by a machine , such as a computer , the machine becomes an apparatus for practicing aspects of the subject matter disclosed herein . as used herein , the term “ machine - readable medium ” shall be taken to exclude any mechanism that provides ( i . e ., stores and / or transmits ) any form of propagated signals . in the case of program code execution on programmable computers , the computing device will generally include a processor , a storage medium readable by the processor ( including volatile and non - volatile memory and / or storage elements ), at least one input device , and at least one output device . one or more programs that may utilize the creation and / or implementation of domain - specific programming models aspects , e . g ., through the use of a data processing api or the like , may be implemented in a high level procedural or object oriented programming language to communicate with a computer system . however , the program ( s ) can be implemented in assembly or machine language , if desired . in any case , the language may be a compiled or interpreted language , and combined with hardware implementations . although the subject matter has been described in language specific to structural features and / or methodological acts , it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above . rather , the specific features and acts described above are disclosed as example forms of implementing the claims .