c# - que - ¿Buena o mala práctica para Diálogos en wpf con MVVM?

tutorial mvvm wpf c#

Question

Últimamente tuve el problema de crear y editar diálogos para mi aplicación wpf.

Todo lo que quiero hacer en mi código es algo como esto. (Uso principalmente el primer enfoque de viewmodel con mvvm)

ViewModel que llama a una ventana de diálogo:

var result = this.uiDialogService.ShowDialog("Dialogwindow Title", dialogwindowVM);
// Do anything with the dialog result

¿Como funciona?

Primero, creé un servicio de diálogo:

public interface IUIWindowDialogService
{
    bool? ShowDialog(string title, object datacontext);
}

public class WpfUIWindowDialogService : IUIWindowDialogService
{
    public bool? ShowDialog(string title, object datacontext)
    {
        var win = new WindowDialog();
        win.Title = title;
        win.DataContext = datacontext;

        return win.ShowDialog();
    }
}

WindowDialog es una ventana especial pero simple. Necesito que contenga mi contenido:

<Window x:Class="WindowDialog"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    Title="WindowDialog" 
    WindowStyle="SingleBorderWindow" 
    WindowStartupLocation="CenterOwner" SizeToContent="WidthAndHeight">
    <ContentPresenter x:Name="DialogPresenter" Content="{Binding .}">

    </ContentPresenter>
</Window>

Un problema con los diálogos en wpf es que el dialogresult = true del dialogresult = true solo se puede lograr en el código. Es por eso que creé una interfaz para mi dialogviewmodel para implementarlo.

public class RequestCloseDialogEventArgs : EventArgs
{
    public bool DialogResult { get; set; }
    public RequestCloseDialogEventArgs(bool dialogresult)
    {
        this.DialogResult = dialogresult;
    }
}

public interface IDialogResultVMHelper
{
    event EventHandler<RequestCloseDialogEventArgs> RequestCloseDialog;
}

Cada vez que mi ViewModel cree que es hora de dialogresult = true , plantee este evento.

public partial class DialogWindow : Window
{
    // Note: If the window is closed, it has no DialogResult
    private bool _isClosed = false;

    public DialogWindow()
    {
        InitializeComponent();
        this.DialogPresenter.DataContextChanged += DialogPresenterDataContextChanged;
        this.Closed += DialogWindowClosed;
    }

    void DialogWindowClosed(object sender, EventArgs e)
    {
        this._isClosed = true;
    }

    private void DialogPresenterDataContextChanged(object sender,
                              DependencyPropertyChangedEventArgs e)
    {
        var d = e.NewValue as IDialogResultVMHelper;

        if (d == null)
            return;

        d.RequestCloseDialog += new EventHandler<RequestCloseDialogEventArgs>
                                    (DialogResultTrueEvent).MakeWeak(
                                        eh => d.RequestCloseDialog -= eh;);
    }

    private void DialogResultTrueEvent(object sender, 
                              RequestCloseDialogEventArgs eventargs)
    {
        // Important: Do not set DialogResult for a closed window
        // GC clears windows anyways and with MakeWeak it
        // closes out with IDialogResultVMHelper
        if(_isClosed) return;

        this.DialogResult = eventargs.DialogResult;
    }
 }

Ahora al menos tengo que crear un DataTemplate en mi archivo de recursos ( app.xaml o algo así):

<DataTemplate DataType="{x:Type DialogViewModel:EditOrNewAuswahlItemVM}" >
        <DialogView:EditOrNewAuswahlItem/>
</DataTemplate>

Bueno, eso es todo, ahora puedo llamar a los diálogos de mis modelos de vista:

 var result = this.uiDialogService.ShowDialog("Dialogwindow Title", dialogwindowVM);

Ahora mi pregunta, ¿ve algún problema con esta solución?

Editar: para completar. El ViewModel debe implementar IDialogResultVMHelper y luego puede subirlo dentro de un OkCommand o algo como esto:

public class MyViewmodel : IDialogResultVMHelper
{
    private readonly Lazy<DelegateCommand> _okCommand;

    public MyViewmodel()
    {
         this._okCommand = new Lazy<DelegateCommand>(() => 
             new DelegateCommand(() => 
                 InvokeRequestCloseDialog(
                     new RequestCloseDialogEventArgs(true)), () => 
                         YourConditionsGoesHere = true));
    }

    public ICommand OkCommand
    { 
        get { return this._okCommand.Value; } 
    }

    public event EventHandler<RequestCloseDialogEventArgs> RequestCloseDialog;
    private void InvokeRequestCloseDialog(RequestCloseDialogEventArgs e)
    {
        var handler = RequestCloseDialog;
        if (handler != null) 
            handler(this, e);
    }
 }

EDIT 2: Utilicé el código de aquí para hacer que mi EventHandler se registre como débil:
http://diditwith.net/2007/03/23/SolvingTheProblemWithEventsWeakEventHandlers.aspx
(El sitio web ya no existe, WebArchive Mirror )

public delegate void UnregisterCallback<TE>(EventHandler<TE> eventHandler) 
    where TE : EventArgs;

public interface IWeakEventHandler<TE> 
    where TE : EventArgs
{
    EventHandler<TE> Handler { get; }
}

public class WeakEventHandler<T, TE> : IWeakEventHandler<TE> 
    where T : class 
    where TE : EventArgs
{
    private delegate void OpenEventHandler(T @this, object sender, TE e);

    private readonly WeakReference mTargetRef;
    private readonly OpenEventHandler mOpenHandler;
    private readonly EventHandler<TE> mHandler;
    private UnregisterCallback<TE> mUnregister;

    public WeakEventHandler(EventHandler<TE> eventHandler,
                                UnregisterCallback<TE> unregister)
    {
        mTargetRef = new WeakReference(eventHandler.Target);

        mOpenHandler = (OpenEventHandler)Delegate.CreateDelegate(
                           typeof(OpenEventHandler),null, eventHandler.Method);

        mHandler = Invoke;
        mUnregister = unregister;
    }

    public void Invoke(object sender, TE e)
    {
        T target = (T)mTargetRef.Target;

        if (target != null)
            mOpenHandler.Invoke(target, sender, e);
        else if (mUnregister != null)
        {
            mUnregister(mHandler);
            mUnregister = null;
        }
    }

    public EventHandler<TE> Handler
    {
        get { return mHandler; }
    }

    public static implicit operator EventHandler<TE>(WeakEventHandler<T, TE> weh)
    {
        return weh.mHandler;
    }
}

public static class EventHandlerUtils
{
    public static EventHandler<TE> MakeWeak<TE>(this EventHandler<TE> eventHandler, 
                                                    UnregisterCallback<TE> unregister)
        where TE : EventArgs
    {
        if (eventHandler == null)
            throw new ArgumentNullException("eventHandler");

        if (eventHandler.Method.IsStatic || eventHandler.Target == null)
            throw new ArgumentException("Only instance methods are supported.",
                                            "eventHandler");

        var wehType = typeof(WeakEventHandler<,>).MakeGenericType(
                          eventHandler.Method.DeclaringType, typeof(TE));

        var wehConstructor = wehType.GetConstructor(new Type[] 
                             { 
                                 typeof(EventHandler<TE>), typeof(UnregisterCallback<TE>) 
                             });

        IWeakEventHandler<TE> weh = (IWeakEventHandler<TE>)wehConstructor.Invoke(
                                        new object[] { eventHandler, unregister });

        return weh.Handler;
    }
}

Answer 1

Este es un buen enfoque y utilicé otros similares en el pasado. ¡Ve a por ello!

Una cosa menor que definitivamente haría es hacer que el evento reciba un booleano para cuando necesite establecer "falso" en DialogResult.

event EventHandler<RequestCloseEventArgs> RequestCloseDialog;

y la clase EventArgs:

public class RequestCloseEventArgs : EventArgs
{
    public RequestCloseEventArgs(bool dialogResult)
    {
        this.DialogResult = dialogResult;
    }

    public bool DialogResult { get; private set; }
}

Answer 2

He estado utilizando un enfoque casi idéntico durante varios meses, y estoy muy contento con él (es decir, todavía no he sentido el impulso de reescribirlo por completo ...)

En mi implementación, uso un IDialogViewModel que expone cosas como el título, los botones de standad para mostrar (para tener una apariencia uniforme en todos los cuadros de diálogo), un evento RequestClose y algunas otras cosas para poder controlar la ventana tamaño y comportamiento

Answer 3

Si está hablando de ventanas de diálogo y no solo de los cuadros de mensaje emergentes, considere mi enfoque a continuación. Los puntos clave son:

1. Paso una referencia al Module Controller al constructor de cada ViewModel (puede usar la inyección).
2. Ese Module Controller tiene métodos públicos / internos para crear ventanas de diálogo (simplemente crear, sin devolver un resultado). De ahí que para abrir una ventana de diálogo en ViewModel escribo: controller.OpenDialogEntity(bla, bla...)
3. Cada ventana de diálogo notifica sobre su resultado (como OK , Guardar , Cancelar , etc.) a través de Eventos Débiles . Si usa PRISM, entonces es más fácil publicar notificaciones usando este EventAggregator .
4. Para manejar los resultados del diálogo, estoy usando la suscripción a las notificaciones (de nuevo Weak Events y EventAggregator en caso de PRISM). Para reducir la dependencia de tales notificaciones, use clases independientes con notificaciones estándar.

Pros:

• Menos código. No me importa usar interfaces, pero he visto demasiados proyectos donde el uso excesivo de interfaces y capas de abstracción causa más problemas que ayuda.
• Abrir ventanas de diálogo a través de Module Controller es una forma simple de evitar referencias fuertes y aún permite usar maquetas para probar.
• La notificación a través de eventos débiles reduce la cantidad de posibles fugas de memoria.

Contras:

• No es fácil distinguir la notificación requerida de los demás en el controlador. Dos soluciones:
  • enviar un token único al abrir una ventana de diálogo y verificar ese token en la suscripción
  • utilice clases de notificación genéricas <T> donde T es la enumeración de las entidades (o por simplicidad puede ser el tipo de ViewModel).
• Para un proyecto debe haber un acuerdo sobre el uso de clases de notificación para evitar su duplicación.
• Para proyectos enormemente grandes, el Module Controller puede verse abrumado por métodos para crear ventanas. En este caso, es mejor dividirlo en varios módulos.

PD. He estado usando este enfoque desde hace bastante tiempo y estoy listo para defender su elegibilidad en los comentarios y proporcionar algunos ejemplos si es necesario.