A bit of this is opinion and style . . . Here's my approach:
Question 1:
I have a utility class that handles any confirmation, and I use the lightweight messaging in MVVM Light to handle communication between the view, the confirmation, and the viewmodel.
Edit: A bit more information on point 1
From within my Command, I will send a message along the lines of
"ConfirmDeletionMessage", which is then picked up by my dialog utility
class. The dialog utility class displays the appropriate message to
the user, and checks the results. Based on the results, it will
either broadcast a "DeletionConfirmedMessage" or
"DeletionCanceledMessage," which is then handled by the ViewModel to
either complete or cancel the delete.
There is some risk involved if you have multiple subscribers to this
message, as you won't know what order they're going to be handled,
but if you have strict management on message consumers, or ensure
that they are able to run in a random order, this approach works
pretty well, and it separates your View and Model code in a testable
fashion.
Question 2:
This is a tough one, and it is going to depend on your overall application. I'm personally a fan of putting it in the item's viewmodel. That way, you don't have to worry about your third question as much. Instead, the delete action simply works on the item you're dealing with. However, if you have to act on data outside of your list item (like removing it from the list), it makes more sense for the command to be on the parent viewmodel.
Question 3:
Use the CommandParameter property. You can bind this to whatever you want.
EDIT to Answer #2
Mark Green (who commented below) got me thinking. I originally adopted this approach for WP7, and it absolutely suited what I needed to do. However, there are other ways of handling this that should absolutely be considered. Another option is a "confirmation class" that can be used by your viewmodel. If you are using an IoC kernel, this becomes easy to do with constructor / property injection. Alternatively, if you have other methods of getting the class, do so, but do it in a way that you can mock out in testing. It might look something like this:
public class ExampleViewmodel : ViewModel
{
private IConfirmDialogManager _dialogManager;
public ExampleViewmodel(IConfirmDialogManager dialog)
{
_dialogManager = dialog;
}
// ... code happens ...
private void DeleteCommand()
{
bool result = _dialogManager.Confirm("Are you sure you want to delete?");
}
}
With an IConfirmDialogManager interface that looks like this:
public interface IConfirmDialogManager
{
bool Confirm(string message);
}
Which you would then implement appropriately.
