Architecture – prism and multiple screens

Architectureguipatterns-and-practicesui

OK – I am studying Prism a little because of a "free weekend" offer on Pluralsight. As this is proving too complex for me, I went to the Prism book and looked at the forward, and this is what it said:

What comes after “Hello, World?”

WPF and Silverlight developers are
blessed with an abundance of excellent books… There’s no lack of tutorials on
Model-View-ViewModel … But they stop short of
the guidance you need to deliver a non-trivial application in full.

Your first screen goes well. You add a second screen and a third.
Because you started your solution with the built-in “Navigation
Application Template,” adding new screens feels like hanging shirts on
a closet rod. You are on a roll. Until the harsh reality of real
application requirements sets in.

As it happens, your application
has 30 screens not three. There’s no room on that closet rod for 30
screens. Some screens are modal pop-ups; you don’t navigate to a
pop-up. Screens become interdependent such that user activity in one
screen triggers changes that propagate throughout the UI. Some screens
are optional; others are visible only to authorized users. Some
screens are permanent, while other screens can be opened and closed at
will. You discover that navigating back to a previously displayed
screen creates a new instance. That’s not what you expected and, to
your horror, the prior instance is gone along with the user’s unsaved
changes.

Now the issue is, I don't relate to this description. I've never been a UI programmer, but same as everyone else I'm using Windows apps such as MS-Office, and web sites such as Amazon, Facebook and StackExchange. And I look at these and I don't see many "so many screens" issues!

Indeed, the only applications having many windows I can think of is Visual Studio. Maybe also Visio, a little. But take Word – You have a ribbon and a main window. Or take Facebook: You have those lists on the left (Favorites, Lists, Groups etc.), the status middle, the adds and then the Contacts sidebar. But it's only one page.

Of course, I understand that in enterprise scenarios there are dashboad applications where multiple segments of the screen are updated from multiple non-related services. This I dig. But other scenarios?

So – What am I missing? What is the "multiple screens" monster Pirsm is supposed to be the silver bullet solution for? Shoud I invest in studying Prism in addition to learning WPF or ASP.NET MVC?

Best Answer

I guess the problem you are having is not Prism related. The question is about GUI design of an application, specifically, your question is about why use multiple screens (windows, pages, etc.).

You have found a good answer for simplifying user interface in the text of your question, namely many applications use 1 page at a time.

Multiple screen/page is usually, though fancy, is confusing for many users (this of course depends on your users skills) not only for programmers!

The 1 page strategy works for Word, Wizards, Configuration screens, Setup programs and many more.

When you use this approach you greatly simplify the programming of the GUI (in case you are trying to handle concurrency of data showing in many screens). Although 'binding' may be able to take care of part of this, still, it is not very easy in some cases.

My suggestion is that you stop programming and start designing the user interface based on the customer business function. Think of what the user needs to do for each business function. Determine what information is required from the system so the function be complete. Design the flow for this function based on that. Do this for the other functions, then review and refine your flow. Consider different user roles in this process. Eventually you will be able to find the optimal GUI design. Now, this may involve more than 1 page/screen but resist this unless it is necessary.

In short, design first before coding.

Good luck.

Related Solutions

Design – Multi-screen MVVM architecture/design – Should the “screen” ViewModels contain sub-ViewModels

Normally I have one overarching ApplicationViewModel that takes care of initializing ViewModels for separate screens, like this, however because of the nature of your application, it sounds like your CompanyOverviewScreenViewModel should work fine for this purpose.

Typically I would have is my main application initialize the top-level data context, and each ViewModel from there is in charge of creating/maintaining viewmodels below it.

For example :

public partial class App : Application
{
    protected override void OnStartup(StartupEventArgs e)
    {
        base.OnStartup(e);

        var mainApp = new CompanyOverviewWindow();
        var appData = new CompanyOverviewScreenViewModel();
        mainApp.DataContext = appData;
        mainApp.Show();
    }
}

The CompanyOverviewScreenViewModel would contain a collection of CompanyModel objects, and upon selection each CompanyModel object would be displayed to the user in some kind of ContentControl or UserControl. Each CompanyModel would further have a collection of EmployeeModel objects that could also be selected and displayed.

Keep in mind that a ViewModel is really just a model of the View. For example, it sounds like you only want to display Employee objects, so using the EmployeeModel directly is perfectly acceptable. But if you wanted to provide the ability to update the EmployeeModel and include items like Save, Cancel, Delete, etc you would probably want a ViewModel to contain the extra code that is unrelated to the Employee data object itself.

In that same vein, because you want to do things like track the Selected Employee of each CompanyModel, something not normally part of the Company data object, it might make sense to use a CompanyViewModel object at that layer too. Sometimes for something as simple as just tracking selection though, I'll just add it the object model. It really depends on how big or how structured the application is.

Overall what you have now looks like you're going in the right direction, although I did have some concern about your image where it says "Each screen creates ViewModels.." in the top left corner. I typically do not advocate for a view-first approach to MVVM and WPF, and would recommend a ViewModel-first approach instead, as I described here.

How to Handle Unhandled Exceptions in C#

You have to expect your program to terminate for more reasons than just an unhandled exception anyway, like a power failure, or a different background process which crashes the whole system. Therefore I would recommend to terminate and restart the application, but with some measures to mitigate the consequences of such a restart and minimize the possible data loss.

Start with analysing the following points:

How much data can actually get lost in case of a program termination?
How severe is such a loss really for the user? Can the lost data reconstructed in less than 5 minutes, or are we talking about losing a days work?
How much effort is it to implement some "intermediate backup" strategy? Don't rule this out because "the user would have to enter a change reason" on a regular save operation, as you wrote in a comment. Better think of something like a temporary file or state, which may be reloaded after a program crash automatically. Many types of productivity software does this (for example MS Office and LibreOffice both have an "autosave" feature and crash recovery).
In case data was wrong or corrupted, can the user see this easily (maybe after a restart of the program)? If yes, you may offer an option to let the user save the data (with some small chance it is corrupted), then force a restart, reload it and let the user check if the data looks fine. Make sure not to overwrite the last version that was saved regularly (instead write to a temporary location/file) to avoid corrupting the old version.

If such an "intermediate backup" strategy is a sensible option depends ultimately on the application and its architecture, and on the nature and structure of the data involved. But if the user will loose less than 10 minutes of work, and such a crash happens once a week or even more seldom, I would probably not invest too much thought into this.

Best Answer

Related Solutions

Design – Multi-screen MVVM architecture/design – Should the “screen” ViewModels contain sub-ViewModels

How to Handle Unhandled Exceptions in C#

Related Topic