Controller MVC e disaccoppiamento spiegato

Question

Controller MVC e disaccoppiamento spiegato

#1 da (1 voti)
#2 da (0 voti)

3

In questo articolo puoi vedere che La vista ha (utilizza o aggrega) il controller e ConcreteView ha il modello Concrete.

public abstract class View 
{ 
    public abstract void Update(); 
    private readonly Controller Controller; 
    protected View() 
    { 
    } 
    protected View(Controller controller) 
    { 
        Controller = controller; 
    } 
    public void ContextInterface() 
    { 
        Controller.AlgorithmInterface(); 
    } 
} 

public class ConcreteView : View 
{ 
    private object ViewState; 
    private ConcreteModel Model { get; set; } 
    public ConcreteView(ConcreteModel model) 
    { 
        Model = model; 
    } 
    public override void Update() 
    { 
        ViewState = Model.ModelState; 
    } 
}

Quindi questo è considerato il classico MVC di GoF. Non vedo dove la vista non sia a conoscenza del modello e viceversa. Voglio dire, cosa succede se mettiamo il puntatore del modello nella vista com'è adesso e non usiamo il controller. Qual è il problema qui? Che cosa questo modello di strategia fa per me (vedi nell'articolo). Inoltre, per quanto ne so, in MVC la vista non dovrebbe conoscere il modello e il modello della vista. Quindi se hai un riferimento nella vista del modello, non significa che si conoscono l'un l'altro?

design-patterns mvc

posta Narek 16.09.2015 - 18:38

fonte

2 risposte

Leggi altre domande sui tag design-patterns mvc

iOS Best practice per la gestione degli oggetti del modello Imporre le regole di aggregazione nel dominio di gestione degli acquisti

score 1 · Answer 1

La vista ha bisogno del modello per aggiornare la sua vista del modello (qui il modello potrebbe essere un'astrazione o una concrezione). Il modello sa che ci possono essere viste astratte che sono interessate agli aggiornamenti, ma il modello non conosce il tipo concreto di View (s).

Il controller cambia il modello. Se c'è un elemento della vista che consente la modifica, la vista avrà bisogno di un controller. Altrimenti, la vista non avrebbe bisogno di un controller.

score 0 · Answer 2

La tua vista MVC dovrebbe essere effettivamente associata a un'interfaccia non a un modello concreto. Ciò consente di eseguire il disaccoppiamento mediante il quale la vista può accettare qualsiasi IModel che rispetti le sue aspettative. Per metterlo in contesto usando il tuo codice:

public abstract class View 
{ 
    public abstract void Update(); 
    private readonly IController Controller; 
    protected View() 
    { 
    } 
    protected View(IController controller) 
    { 
        Controller = controller; 
    } 
    public void ContextInterface() 
    { 
        Controller.AlgorithmInterface(); 
    } 
} 

public class ConcreteView : View 
{ 
    private object ViewState; 
    private IModel Model { get; set; }
    public ConcreteView(IModel model) 
    { 
        Model = model; 
    } 
    public override void Update() 
    { 
        ViewState = Model.ModelState; 
    } 
}

In diversi framework potresti non avere questo tipo di controllo granulare sulla definizione della vista, ma i principi in realtà non cambiano. Se tutto il tuo codice è contro un'interfaccia (ri: contratto), allora l'implementazione concreta non conta più finché tutti gli oggetti aderiscono ai contratti. Quando si ha a che fare con gli oggetti framework, le interfacce potrebbero non essere disponibili e potrebbe essere necessario ricorrere a questa stessa tecnica con le classi base di framework.