I'm working on an Editor-GUI (C#, WPF, Windows-Desktop) for a quite complex domain model. The domain model consists of many different node types mainly coupled in a hierarchie. Also it is possible to create links/references from one object to another (which can be 1:m). You could imagine it as a kind of syntax tree with Class/Method definitions and calls to that methods (this is just a rought equivalent). At the moment the model is represented in-memory by different classes.

Now my problem is, how to monitor changes in the model, so that I can update different components of my gui and track internal states like "model has changed", trigger validation etc.

At the moment I'm using a mix of edit-functions that trigger some events to inform others and in some places the INotifyChanged-Logic from .NET/WPF.

In the end this works not very well and consise, especially for my linked objects - they have no hard reference inside the model, they are referenced by an identifier. Additionally I have to pollute my domain-model with all those notify-change logic, which ties this very tight to the framework.

At the moment I see 3 possible solutions:

  1. Strictly pass all edits through an Editor-Service, so that could inform all other components/subscribers in an unified way. Cons: If you forget to use the service and edit an object "directly" no one will get informed, and editing simple properties might become cumbersome.

  2. Use INotify... everywhere and create hard links for references. Cons: this will make the domain model even more complex and every Object still has to inform some kind of message-broker so that other components can be updated.

  3. Use a message-based approach like "Change property XYZ on Object with ID 123" and send this message to all components and objects, and someone feels responsible to do that. Cons: This will create an insane overhead of Edit-Message-Classes and one will loose many possibilities concerning type-safety and refactoring.

So is there some best-practice way to edit a complex model and monitor model-changes?


  • Does your editor follow a MVVM approach?
    – Doc Brown
    Nov 16 '20 at 16:52
  • Basically yes, at least thats where it should be in the end :-) Nov 17 '20 at 12:19

I see two general approaches here:

  1. either the domain model itself gets the responsibility of detecting changes and generating events for any change to its attributes

  2. or a component like your suggested Editor gets the responsibility for this.

#1 is IMHO only feasible when the domain model follows some generative approach and its API is created by some code generator (or when the domain model is so small you can do this manually, which seems not to be the case here). That would allow to generate the event mechanics into all writing method afterwards. I guess that's not your situation, and your domain model probably consists of POCOs.

Hence I would probably go the "Editor" approach, with the following things in mind. You wrote

If you forget to use the service and edit an object "directly" no one will get informed

Then disallow any direct editing for any other component in your system except the Editor service. Keep all "read" methods public, make all "write" methods only "internally" visible, and use the [assembly: InternalsVisibleTo()] attribute to allow only the editor to change something. Then the compiler will it make impossible to "forget" using the editor from the GUI.

You also wrote

editing simple properties might become cumbersome.

Well, if you want to monitor changes to each and every property, you have to change at least something. You won't get that for free. If this is a problem depends on how many of such operations your GUI really has, which cannot be hidden behind some macroscopic editor operation.

I think if there will be really a lot of such "simple property changes" required, you may try to develop some generic Editor operations using Reflection and nameof, which will make the usage not hopefully less cumbersome.

  • After taking a closer look, it turnes out, that the amount of REALLY used edit-operations is indeed not as large as supposed by just looking at the idea of a "complete" editor. So I will go down the road with the Editor approach, because the model is indeed POCO and is used for xml-serialization too. [assembly: InternalsVisibleTo()] was new to me, thanks for that. Nov 23 '20 at 13:04

Based on my understanding of how your components are structured

Also it is possible to create links/references from one object to another (which can be 1:m)

I think the way to go in this situtation is an implementation of the Observer Pattern.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.