In che modo MVC è diverso da Layered

Se consideri qualsiasi progetto di grandi dimensioni o applicazione aziendale, mvc viene utilizzato solo nel livello di presentazione. Qui il modello agirà semplicemente come modello di vista. A volte il modello viene mantenuto in un progetto separato e condiviso tra tutti i livelli, BAL, DAL e PL. Non si può dire che sia un'architettura client-server perché nell'architettura di livello diversi livelli sono ospitati in server diversi.

Le applicazioni MVC e Tiered sono problemi molto diversi. Uno è un modello architettonico e l'altro è un modello design .

In realtà, non c'è nulla che mantenga MVC e l'architettura stratificata come idee reciprocamente esclusive.

• Modello : hai oggetti dominio che rappresentano le entità logiche dell'applicazione
• Controller : hai oggetti / azioni che mappano l'interazione dell'interfaccia utente con il modello di dominio.
• Visualizza : hai presentazioni per gli oggetti di dominio che interagiscono con i controller e si legano in qualche modo agli oggetti.

Le applicazioni a livelli possono avere la disposizione del modello in un "Data Layer" e incorporare la logica del controller in un "Application Layer", e infine legare tutto insieme usando le viste nel "Presentation Layer".

Più spesso poi no, questi layer sono spesso pesanti e l'intero approccio MVC può essere applicato in un livello, con un back-end del database.

1) In MVC , there is the Model , View , Controller which is in essence a three layer architecture with View on top , Controller in the middle , Model on the bottom and all three layers are only able to communicate with the layers above and beneath them only which is exactly the same as layered architecture . What is the actual difference between them ??

Sono componenti distinti dell'architettura. In teoria, ognuno può essere scambiato senza influenzare gli altri.

Ad esempio, il visualizzatore ha due scopi:

1. Consenti all'utente di visualizzare il modello.
2. Consenti all'utente di modificare / aggiornare il modello.

Due visualizzatori possono differire in:

1. Cosa permettono la visualizzazione dell'utente e i meccanismi per visualizzarli.
2. Cosa permettono all'utente di cambiare e ai meccanismi forniti per cambiare.

Se esiste un business case per la presenza di due viewers, non ci sono ostacoli tecnici per supportare entrambi.

Se esiste un business case per sostituire il visualizzatore esistente con un altro visualizzatore, non ci sono ostacoli tecnici per farlo.

Il Controller funge da livello API per costruire, interrogare e aggiornare gli oggetti nel modello. Parlando da uno sfondo CAD, il livello API potrebbe fornire funzioni a:

1. Sfaccettatura di una parte per scopi di visualizzazione.
2. Fornisci query geometriche, ad esempio il punto più vicino sulla faccia, dato un altro punto.
3. Calcola l'intersezione di due superfici per definire il bordo condiviso di due facce.
4. Etc.

Il controller non si occupa di chi richiede una determinata azione. Se supporta l'azione, lo esegue. Aggiornamenti e miglioramenti al controller possono essere resi indipendenti dal Viewer e dal Modello.

Il modello è i puri dati dell'applicazione. Server i dati sul controller. È il meno flessibile del lotto. È molto facile rompere il controller apportando modifiche al modello che non sono retrocompatibili o introducendo bug durante la modifica del modello. Anche se è separato dal Viewer e dal Controller, qualsiasi modifica al Modello dovrà essere fatta attentamente in modo che il Controller e il Visualizzatore siano meno interessati da esso.

2) Isn't MVC a form of client server architecture ??

Potrebbe essere. Nella pura architettura del server client, il client e il server tendono ad essere meno legati rispetto a un'architettura MVC. Un browser Web è raramente collegato al server HTTP. D'altra parte, la GUI di un'applicazione CAD è molto chiusa legata al modello sottostante. Non esiste un'interfaccia generica con interfaccia grafica che possa essere utilizzata per qualsiasi pacchetto CAD.

3) Master-Slave seems exactly like 2 tier client-server where the server is the Master and the client is the slave , I dont understand how Master-Slave differs from Client-Server

È l'opposto. Il client è il master e il server è lo slave. Il server risponde alle richieste fatte dal client.