Design decision in a larger class hierarchy
-
This is a long story which I will try to make as short as possible, thanks for your patience in advance :) I am working on a program that has evolved from a web application to a Windows Forms client, then was ported to a WPF client and now has become a XNA client with a homemade UI. Porting the application from Windows Forms to WPF and now or own UI was possible because it was based on a (modified) MVP pattern. It was just a matter of porting the MVP framework to the new UI and then redesigning the views. The presenters or other logic remained the same. You may have noted the (modified) above. This modification deals with the application's workflow and and controlling the application's workspace. The main workspace is nothing else than an empty window. The application can then subdivide it as needed and assign the subworkspaces eventually to presenters which display views in them. Seen from the perspective of the UI, workspaces are windows(!), panels and all kinds of layout controls. Now, while working on my own UI, I have stumbled over a question which I already swept under the rug in the initial Windows Forms implementation and kept under the rug in the WPF implementation. Now I cannot put it off any longer, but I also sit between two chairs. My UI has a hierarchy of controls, very similar to what you are accustomed to from Windows Forms or WPF. With our MVP being an inegral part of the UI, windows (or forms, if you like) are in the 'workspace' branch of the class hierarchy. Traditionally UIs don't have any concept of workspaces and treat windows just like any other control. This leaves me with those choices: 1) Windows are workspaces. To stay consistent with the established architecture, the correct procedure will be to open an empty window and assign it to a presenter as workspace. The presenter will then show its view inside this window. The option to open a simple dialog on the fly, like a MessageBox, will be lost. 2) Windows are controls. This will stand in opposition to the application's main workspace, which must be a window. Also, this would be absolutely against the existing architechture. Dialogs would always have to be opened like controls and would be outside the MVP. Of course I tend to 1), but I don't like departing from the accustomed way of opening a window or dialog. Seeing a MessageBox (or any other 'common dialog') as yet another control of the view is practical at times. Simply implementing both versions looks to me like bad class design and would also introduce significan