I have an XML file that contains configuration information for a system. I can serialize/deserialize the XML into a hierarchy of objects that describe the configuration (and no more) and then pass those objects to a task which performs work based on the data in the objects.

What I want to do is to build a specialized editor for my XML to allow a user to construct the configuration file via point and click as opposed to opening it up in a text editor and manually changing things. The idea being to provide consistency and error checking when the configuration information is entered (as opposed to the run time system saying FU and having to figure out what you did wrong). Because of the normalization of data in the XML there would be almost a 1 to 1 correspondence of XML elements/attributes to user edit fields on the screen.

However when I think of this in MVVM terms, it seems I have two choices, neither of which I like.

  1. A separate View Model hierarchy duplicates all of the fields in the XML model while adding error checking and everything else needed (such as data binding and property updates etc) to couple a View Model to a view in WPF using MVVM.

  2. The XML model sucks in everything that a separate View Model would do, but I end up having a single (albeit horrendous), consistent object hierarchy.

So it seems either I duplicate the hierarchy, creating consistency issues, or I violate having separate view and domain models and create a big ball of code.

Is there another way that I can structure my editor that avoids these two designs and their pitfalls?

This question from 2012 asked what may seem be a duplicate, but the answers are inconsistent to say the least.

  • 1
    What's wrong with Option 1 exactly? This isn't duplication - different models at different architectural layers serve different purposes; all of this is completely normal and necessary for clean separation. This kind of thing happens all the time for Database persistence with EntityFramework, so why should XML Persistence be any different? Consider what might happen if you need to reuse your XmlSerializer models for a different UI such as ASP.NET MVC, or even a REST service; would you really want those models to contain the baggage of your MVVM stuff? Oct 18, 2017 at 20:45
  • @BenCottrell No it is not pure duplication because it does have a functional difference, but the structure of option 1 is going to virtually mirror the structure of the domain model, thus I feel there are some anti-DRY principles at play. I can get away with option 2 as this code will never exist outside of this one program I am building - but it offends me to even consider it.
    – Peter M
    Oct 18, 2017 at 21:07
  • I'd suggest that the real value of having UI-specific models is the ability to let your UI requirements evolve into something far more complex without worrying about your underlying data persistence. for example, a user might click on an item in the UI, which might be represented as a bool state in one of your models which binds to a Visible property in some XAML control, or affects a Data Template. Or perhaps the UI model will hold a Message string for some temporary notification on the UI, or maybe some X,Y grid screen coordinates, etc. Oct 18, 2017 at 21:34
  • You could build an editor that creates structured nested tags and its attributes (more generic, instead of directly reflect the structure of the config). Then you provide some specifics (eg: you have a predefined set of tag names to choose). After that, you can implement on your gui layer some validator that checks if the structure created is valid based on your config info structure. Oct 19, 2017 at 11:23

1 Answer 1


MVVM tends to become a bit clunky when the application is straight forward (like the 1-1 mapping of fields you mention). The benefits come with apps of relative complexity and medium and big size.

Thus, if your editor is a simple application you may be better off avoiding (or using a light-MVVM design as in your option 2) all the ceremony that comes with MVVM.

Regarding your option 1, I don't really agree that the ViewModel is going to be just a pure "gateway" between the View and the XML parser. You mention error validation, etc. which are all tasks mostly suitable for the ViewModel. I think when you start writing the editor, you will very quickly see most of the functions more suitable in the ViewModel rather than in any of the other parts.

There is, also, another point here. You are writing an XML editor today but later on you may realise that the GUI you built suits very nicely in another application or a new file type is invented in the future and you want to use it with your editor. If you don't follow a design pattern such as MVVM, you may be limited in how much of the app you can use.

Lastly, I don't think option 2 is a good MVVM design. Your model should not do what the ViewModel does and vice versa. The XML parser is your model and the ViewModel does all the required alterations/conversions and manipulation of data in order for the View to be able to present it. Consider it as a space in between the model and the view where you can "play" with the data before they are presented or are fed back to the model.

There is, also, another benefit having a middle ground. A ViewModel can link to more than one Models. For example, you can have your XML parser and another one more efficient and you allow the users to select which one to use. In option 2, you will end up with a huge model (which will violate a couple of SOLID principals). If you have a ViewModel, both models can be linked to it and used accordingly giving you a cleaner code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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