MVVM Design – When to Use the Messenger (Mediator) Pattern

The real key is to separate logic from effects. IMO, this is the primary goal of any architectural pattern. Both MVP and MVVM (if done right) do a decent job of enforcing this separation.

As long as you have a system to enforce this separation that is consistently used, then your architecture is good as far as I'm concerned.

Once that primary goal is met, the next question is, how easy is it to be consistent? When comparing two architectures that are both successfully keeping logic and effects separate, the better architecture is the one that requires the least boilerplate.

By "boilerplate" I am explicitly calling out the requirement of creating test doubles in unit tests. If you need to create a test double in order to unit test your logic, it means you have injected effects into your logic, that now must be mocked out in order to test said logic. Ideally, that won't be necessary and the architecture that requires fewer test doubles when unit testing logic is better by this view.

Now there are lot of variations of both the MVP and MVVM pattern and you haven't specified exactly how you have or plan to implement the two architectures, so I won't call out either as being better or worse. But if I were looking at your code, the above two criteria would be what I use to "tip the balance."

Can I (1) test the logic in the system without tripping effects and (2) do so without creating a bunch of test doubles (mocks, fakes and stubs) in the process?

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.