mercoledì 29 dicembre 2010

Enterprise design: MVC, MVP e MVVM - parte 4


Oggi si parla di teoria e in particolare di pattern architetturali. Nella prossima puntata inizierò ad analizzare il progetto realizzato sulla base dei principi esposti nella parte 3 e in questo post.

I pattern che vedremo sono il Model-View-Controller, il pattern Model-View-Presenter e la versione modificata da Microsoft, il Model-View-ViewModel

Partiamo dal pattern MVC (Model View Controller)

Model: il model rappresenta i dati che le view visualizzano o modificano. Si può immaginare come una serie di metodi che forniscono alla View i dati da visualizzare e una serie di metodi che il Controller chiama per modificare i dati su richiesta della View.
View: è la parte che l'utente vede e su cui l'utente compie azioni. La View raccoglie i dati provenienti dal Model e indirizza al Controller le azioni fatte dall'utente.
Controller: è la parte che coordina le interazioni tra View e Model. Semplificando raccoglie le azioni compiute sulla View e agisce sul Model perchè vengano restituite le giuste informazioni.

Il secondo pattern è il MVP (Model View Presenter)

Abbiamo sempre un'architettura basata su 3 livelli ma cambiano le dipendenze. Non abbiamo più il Controller ma uno strato definito Presenter che si occupa di chiedere al Model i dati che poi presenterà alla View adattandoli alle necessità della visualizzazione. La grande differenza è che nel modello MVC il Controller non risponde al View ma chiede al Model di farlo. Nel modello MVP la View comunica esclusivamente con il Presenter ed è assolutamente all'oscuro di cosa ci sia oltre il Presenter.

L'ultimo pattern è il MVVM (Model View ViewModel)

Questo modello nasce dalla constatazione che se esistono meccanismi di databinding bidirezionale allora applicare i modelli precedenti che richiedono la rinuncia all'utilizzo del databinding diventa improduttivo. Il MVVM deriva dal modello MVP, in particolare crea un nuovo modello differente dal modello di dominio per le proprietà che lo adattano alle necessità della View. Il Presenter che possiamo rinominare ViewModel quindi sarà costituito in parte da proprietà del Model e in parte da proprietà derivanti dalla View. Il collegamento ai data è delegato ai meccanismi di databinding.

lunedì 13 dicembre 2010

venerdì 10 dicembre 2010

Enterprise design: i principi - parte 3

Una breve descrizione dei principi di design che sono alla base dei pattern.

KISS (Keep It Simple Stupid): evitare qualunque complicazione non necessaria. Scrivere codice in maniera semplice.

DRY (Don't Repeat Yourself): evitare di ripetere parti di codice in posizioni diverse. Se si ha la necessita' di copiare una funzionalita' probabilmente e' possibile passare attraverso forme di astrazione.

Tell don't Ask: questo principio e' legato con il concetto di incapsulamento. E' meglio dire agli oggetti cosa devono fare piuttosto che chiedere il loro stato e poi decidere l'azione da compiere. Questo permette di mantenere il concetto di responsabilita' e diminuire la dipendenza tra oggetti.

YAGNI ( You Ain't Gonna Need It): non metterlo se non e' necessario. Il concetto e' piuttosto ovvio, non scrivere codice che non e' necessario. La tendenza ad aggiungere funzioni non richieste solo perche' si pensa che potrebbero in futuro essere utili rischia solo di aggiungere linee da scrivere e poi da controllare. La metodologia TDD aiuta ad evitare ogni tentazione.

SoC ( Separation of Concerns): e' il processo di separazione di una parte di software in singole funzioni che incapsulano singoli comportamenti e dati che possono essere usati da altre classi.

Il prossimo gruppo di principi vengono raggruppati sotto la sigla SOLID

S Single Responsability Principle (SRP): questo principio e' strettamente legato al concetto della Separation of Concerns. Ogni oggetto deve avere un singolo motivo per cambiare e un singolo ambito di responsabilita'. Costruire grandi classi monolitiche rende il software meno leggibile e piu' difficile da mantenere.

O Open Closed Principle (OCP): una classe deve essere aperta per l'estendibilita' e chiusa per le modifiche. In altri termini nuovi comportamenti vanno aggiunti estendendo la classe senza modificare i comportamenti interni. Questa buona abitudine permette di evitare di rompere il funzionamento di classi esistenti e altre classi che da queste dipendono.

L Liskov Substitution Principle (LSP): questo principio suggerisce di creare classi derivate che possano sostituire la classe genitore sempre e senza modifiche. Quindi le classi derivate non modificano il comportamento della classe genitore nel rispetto del principio OCP.

I Interface Segregation Principle (ISP): il principio consiglia di implementare nei client solo quelle interfacce che vengono usate. Ovvero invece di progettare una grossa interfaccia pensare di dividerla per gruppi di client per le sole funzione che realmente vengono poi usate. Si cerca cosi' di evitare forti accoppiamenti non necessari.

D Dependency Inversion Principle (DIP): e' necessario dipendere da classi astratte piuttosto che da classi concrete. Questo principio sottolinea la convenienza di usare interfacce piuttosto che implementazioni. Si ottiene maggiore flessibilita' e minori accoppiamenti.

La prossima puntata sara' dedicata alla descrizione del pattern MVC e al MVP.