Come rendere meno dolorosa la creazione di viewmodels in fase di esecuzione

Il problema delle dipendenze durante l'avvio di un nuovo modello di visualizzazione può essere gestito con IOC.

public class MyCustomViewModel{
  private readonly IShoppingCartWebService _cartService;

  private readonly ITimeService _timeService;

  public ProductDTO ProductDTO { get; set; }

  public ProductDetailsViewModel(IShoppingCartWebService cartService, ITimeService timeService){
    _cartService = cartService;
    _timeService = timeService;
  }
}

Durante l'impostazione del contenitore ...

Container.Register<IShoppingCartWebService,ShoppingCartWebSerivce>().As.Singleton();
Container.Register<ITimeService,TimeService>().As.Singleton();
Container.Register<ProductDetailsViewModel>();

Quando ti serve il tuo modello di visualizzazione:

var viewmodel = Container.Resolve<ProductDetailsViewModel>();
viewmodel.ProductDTO = myProductDTO;

Quando utilizzi un framework come caliburn micro spesso è già presente qualche forma di contenitore IOC.

SomeCompositionView view = new SomeCompositionView();
ISomeCompositionViewModel viewModel = IoC.Get<ISomeCompositionViewModel>();
ViewModelBinder.Bind(viewModel, view, null);

Lavoro quotidianamente con ASP.NET MVC e ho lavorato su un WPF da oltre un anno e questo è il modo in cui lo vedo:

MVC

Il controllore dovrebbe orchestrare le azioni (prendi questo, aggiungilo).

La visualizzazione è responsabile della visualizzazione del modello.

Il modello in genere comprende dati (ad esempio UserId, FirstName) nonché lo stato (ad esempio Titoli) e di solito è specifico della vista.

MVVM

Solitamente il modello contiene solo dati (ad esempio UserId, FirstName) e di solito viene passato intorno

Il modello di visualizzazione comprende il comportamento della vista (metodi), i suoi dati (modello) e le interazioni (comandi) - simile al pattern MVP attivo in cui il relatore è a conoscenza del modello. Il modello di vista è specifico della vista (1 view = 1 view model).

La visualizzazione è responsabile della visualizzazione di dati e associazione dati al modello di visualizzazione. Quando viene creata una vista, di solito viene creato il relativo modello di visualizzazione associato.

Ciò che dovresti ricordare è che il pattern di presentazione MVVM è specifico per WPF / Silverlight a causa della loro natura di associazione dei dati.

La vista in genere conosce il modello di vista a cui è associato (o un'astrazione di uno).

Ti consiglierei di trattare il modello di visualizzazione come un singleton, anche se è istanziato per visualizzazione. In altre parole, dovresti essere in grado di crearlo tramite DI tramite un contenitore IOC e chiamare su di esso i metodi appropriati per dirlo; caricare il suo modello in base ai parametri. Qualcosa del genere:

public partial class EditUserView
{
    public EditUserView(IContainer container, int userId) : this() {
        var viewModel = container.Resolve<EditUserViewModel>();
        viewModel.LoadModel(userId);
        DataContext = viewModel;
    }
}

Come esempio in questo caso, non creerai un modello di visualizzazione specifico per l'utente che si sta aggiornando, invece il modello conterrà dati specifici dell'utente che verranno caricati tramite alcune chiamate sul modello di visualizzazione.

Risposta breve per le tue domande:

1. Sì Stato + Il comportamento porta a questi problemi, ma questo è vero per tutti gli OO. Il vero colpevole è l'accoppiamento di ViewModels che è una specie di violazione SRP.
2. Scritto staticamente, probabilmente. Ma dovresti ridurre / eliminare la necessità di istanziare ViewModels da altri ViewModels.
3. Non che io sappia.
4. No, ma con ViewModels con stato e ampli non collegati; comportamento (come alcuni riferimenti a modelli e alcuni riferimenti a ViewModel)

La versione lunga:

Siamo di fronte allo stesso problema e abbiamo trovato alcune cose che potrebbero aiutarti. Anche se non conosco la soluzione "magica", quelle cose stanno attenuando un po 'il dolore.

1. Implementa modelli associabili da DTO per il rilevamento e la convalida delle modifiche. Questi "Data" -ViewModels non devono dipendere dai servizi e non provengono dal contenitore. Possono essere solo "nuovi" ed escogitati, potrebbero persino derivare dal DTO. La linea di fondo consiste nell'implementare un modello specifico per la tua applicazione (come MVC).

2. Dissocia i tuoi ViewModels. Caliburn rende facile accoppiare i ViewModels insieme. Lo suggerisce persino attraverso il suo modello Screen / Conductor. Ma questo accoppiamento rende i ViewModel difficili da testare, crea molte dipendenze e il più importante: impone il peso della gestione del ciclo di vita di ViewModel su ViewModels. Un modo per separarli consiste nell'utilizzare qualcosa come un servizio di navigazione o un controller ViewModel. Per esempio.

   interfaccia pubblica IShowViewModels {      void Show (oggetto inlineArgumentsAsOnonymousType, string regionId); }

Ancora meglio è farlo con una qualche forma di messaggistica. Ma l'importante è non gestire il ciclo di vita di ViewModel da altri ViewModels. Nei controller MVC non dipendono l'uno dall'altro, e in MVVM ViewModels non dovrebbe dipendere l'uno dall'altro. Integrali in altri modi.

3. Utilizza le tue caratteristiche "a stringhe" / dinamiche dei contenitori. Sebbene sia possibile creare qualcosa come INeedData<T1,T2,...> e applicare i parametri di creazione sicuri per i tipi, non ne vale la pena. Anche la creazione di fabbriche per ogni tipo di ViewModel non vale la pena. La maggior parte dei contenitori IoC fornisce soluzioni a questo. Otterrai errori in fase di esecuzione ma ne valuterà la de-accoppiamento e la testabilità dell'unità. Continui a fare qualche tipo di test di integrazione e quegli errori sono facilmente individuabili.

Come faccio di solito in questo modo (usando PRISM), ogni assembly contiene un modulo di inizializzazione del contenitore, in cui tutte le interfacce, le istanze sono registrate all'avvio.

private void RegisterResources()
{
    Container.RegisterType<IDataService, DataService>();
    Container.RegisterType<IProductSearchViewModel, ProductSearchViewModel>();
    Container.RegisterType<IProductDetailsViewModel, ProductDetailsViewModel>();
}

E date le classi di esempio, sarebbero implementate in questo modo, con il contenitore che viene passato fino in fondo. In questo modo è possibile aggiungere facilmente nuove dipendenze poiché hai già accesso al contenitore.

/// <summary>
/// IDataService Interface
/// </summary>
public interface IDataService
{
    DataTable GetSomeData();
}

public class DataService : IDataService
{
    public DataTable GetSomeData()
    {
        MessageBox.Show("This is a call to the GetSomeData() method.");

        var someData = new DataTable("SomeData");
        return someData;
    }
}

public interface IProductSearchViewModel
{
}

public class ProductSearchViewModel : IProductSearchViewModel
{
    private readonly IUnityContainer _container;

    /// <summary>
    /// This will get resolved if it's been added to the container.
    /// Or alternately you could use constructor resolution. 
    /// </summary>
    [Dependency]
    public IDataService DataService { get; set; }

    public ProductSearchViewModel(IUnityContainer container)
    {
        _container = container;
    }

    public void SearchAndDisplay()
    {
        DataTable results = DataService.GetSomeData();

        var detailsViewModel = _container.Resolve<IProductDetailsViewModel>();
        detailsViewModel.DisplaySomeDataInView(results);

        // Create the view, usually resolve using region manager etc.
        var detailsView = new DetailsView() { DataContext = detailsViewModel };
    }
}

public interface IProductDetailsViewModel
{
    void DisplaySomeDataInView(DataTable dataTable);
}

public class ProductDetailsViewModel : IProductDetailsViewModel
{
    private readonly IUnityContainer _container;

    public ProductDetailsViewModel(IUnityContainer container)
    {
        _container = container;
    }

    public void DisplaySomeDataInView(DataTable dataTable)
    {
    }
}

È abbastanza comune avere una classe ViewModelBase, da cui derivano tutti i modelli di visualizzazione, che contiene un riferimento al contenitore. Finché hai preso l'abitudine di risolvere tutti i modelli di visualizzazione anziché new()'ing , dovrebbe rendere la risoluzione delle dipendenze molto più semplice.

A volte è meglio andare alla definizione più semplice piuttosto che a un esempio completo: link forse leggere l'esempio di ZK Java è più illuminante di quello di C #.

Altre volte ascolta il tuo istinto ...

Is having a lot of ViewModels with both state/behavior a design smell?

I tuoi modelli sono oggetti per mapping di tabelle? Forse un ORM aiuterebbe la mappatura degli oggetti del dominio durante la gestione dell'azienda o l'aggiornamento di più tabelle.