Duplicating Domain Model in View Model or not

Question

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.

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.