DialogManager strategy?

 

A VM can only be paired with a single V at any given time, so the VM that launches your popup is currently bound to the V that displays your list. It cannot also be bound to the popup V that displays the details. You need another VM instance for the popup.

 

You can see an example in TempHire in StaffingResourceSummaryViewModel.EditName(). It's not exactly your scenario, but conceptually the same.

 

        public IEnumerable<IResult> EditName()
        {
            StaffingResourceNameEditorViewModel nameEditor = _nameEditorFactory.CreatePart();
            yield return _dialogManager.ShowDialog(nameEditor.Start(StaffingResource.Id), DialogButtons.OkCancel);
 

            StaffingResource.FirstName = nameEditor.FirstName;
            StaffingResource.MiddleName = nameEditor.MiddleName;
            StaffingResource.LastName = nameEditor.LastName;
        }

 

A VM is simply an object. The entity itself can be a VM. You just have to define a convention, so Cocktail knows how to find the V that goes with a given entity and then you can call the dialog manager with the entity instead of a VM that wraps the entity if you don't have any logic in between. But back to the previous post, you often have UI logic in between that doesn't belong into the entity like converting data for proper display. The HappyHour tutorial actually demonstrates how to use an entity directly as a VM. I forgot which lesson that is in, though.

VM-first makes architecturally for a much cleaner separation of concerns. I would argue it doesn't get much better. All the navigation, decision etc. logic is in one place in the VM and the current state of the VM determines which V is displayed over it. The V is pure look-and-feel at that point and becomes completely replaceable. For example an Admin user could see a completely different view than a regular user. A view should never have logic in it. In fact you should delete all the code-behind files to not even be tempted to add logic to the V. It's all XAML and data-binding. You can hand the V to a designer and they can focus on making it look the best without having to deal with any dependencies on your code. If at some point you don't like the look and feel anymore you can simply replace it with new views without having to change the logic.

Another concern is UI composition. Composing a screen V-first gets messy trying to get the underlying VMs to coordinate with each other. Composing VMs is a lot easier and cleaner. Look at how highly decomposed the UI in TempHire is. Imaging how to wire the pieces up if the composition was driven by the V. 

TempHire is really a good example to demonstrate the benefits of VM-first. If you compare TempHire Silverlight to TempHire WPF you'll notice that 99% of the code is shared. There are one or two places where a compiler directive was necessary to account for differences at the API layer, but other than that the difference between WPF and Silverlight is just at the View level. For example in WPF the root view is typically a Window, where as in Silverlight it's a UserControl that's hosted in the Silverlight plug-in. So, you'll notice that the WPF solution uses different Vs for about half of the VMs. The application logic is completely agnostic to the platform you are using. In fact TempHire started as a Silverlight only project. Then I got requests for a WPF version and it took less than a weekend to port it to WPF. Now I still need to port several styles over, but again that's all presentation. Once we have DevForce working in WinRT it will take very little effort to port TempHire to Metro. In this case it probably will take a littler longer because for Metro one should rethink the UI so it's touch friendly, but again most of that is isolated to the Vs.