Bersani e le parole

Il riassunto visivo del discorso di Bersani sabato in piazza s.giovanni

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.

Enterprise Design: il sito non bastava - parte 2

La lettura del libro "Professional Asp.Net Design Patterns" mi ha portato a riflettere su come organizzare un progetto che fosse più adeguato alle esigenze dell'azienda.

La soluzione di Visual Studio è composta da 6 progetti. I primi cinque sono librerie di classi, l'ultimo è un'applicazione web MVC 2.

I progetti descrivono anche i vari strati in cui ho diviso la soluzione.
Si parte dalla libreria "Model" che contiene le classi che descrivono le entità del dominio. Nel mio caso: il negozio, il prodotto, le categorie merceologiche, il marchio, le categorie editoriali. La libreria si occupa di modellare il comportamento di questi oggetti, con la validazione dei dati.

La persistenza dei dati è gestita tramite le classi del Repository. In questo caso ho implementato un pattern noto cercando di ottenere il massimo disaccoppiamento della base di dati concreta. Questo è ottenuto con l'utilizzo di Interfacce ad esempio la persistenza dell'entità categoria merceologica viene gestita da una classe categoryRepository e dall'interfaccia ICategoryRepository. Gli altri strati utilizzeranno chiamate a metodi dell'interfaccia e non avranno in alcun modo bisogno di sapere quale e' l'implementazione concreta di essi.

La libreria AppService contiene le classi siteservice e shopservice che sono le due classi fondamentali: shopservice in pratica realizza l'API del sistema esponendo tutti i metodi utilizzati dall'applicazione, la classe siteservice adatta questi metodi alla visualizzazione sul sito sfruttando delle classi mapper tra gli oggetti del dominio e le classi dello strato di presentazione.

La libreria ViewModel contiene la modellizzazione dei dati necessari alla visualizzazione delle pagine del sito per ora, ma infuturo potrà contenere visualizzazioni diverse dalla pagina web. Le Pagine derivano dalla classe BaseView che in pratica contiene gli oggetti comuni a tutte le pagine.

Infine la libreria Infrastructure che contiene classi per lo più statiche e che implementano metodi o servizi comuni.

Ultimo progetto è l'applicazione web asp.net mvc 2. Su questo non c'e' molto da aggiungere se non che i controller chiameranno istanze della classe siteservice con il compito di istanziare la giusta classe del viewmodel passata come modello alla view del sito.

Nel prossimo appuntamento un pò di teoria

Enterprise Design: tentativo di andare oltre il solito cms

Oggi il primo test: tutto bene. Il mio ultimo lavoro procede verso la pubblicazione. Il countdown segna -10 giorni più che sufficienti per completare la prima fase.

Vorrei scrivere una serie di post per descrivere tutte le fasi che hanno portato dall'idea alla realizzazione.

Inizio con una breve introduzione che descrive il sistema.

"Il sistema deve funzionare come http://shopmilesandmore.com, quindi deve esserci una vetrina di negozi convenzionati, il visitatore potrà cercare per categoria merceologica o per nome del negozio, arrivati sulla scheda di dettaglio del negozio dovrà necessariamente inserire il numero della sua card. Ogni acquisto effettuato sui siti partner deve essere tracciato in modo che sia possibile riconoscere un tot di punti a fronte dell'acquisto."

Applicazione web su piattaforma .Net 4.0, database Microsoft Sql Server 2008, per il presentation layer un sito asp.net MVC 2.

Nel prossimo post la descrizione dell'architettura.

URL Unexpectedly

Mi è capitato dover far leggere un web service .Net da una pagina asp. La cosa non è particolarmente difficile. Ho utilizzato l'oggetto MSXML2.XMLHTTP facendo poi il parser dell'xml ricevuto.
Ovviamente non è andata come speravo e mi sono scontrato con il seguente errore: "Request format is unrecognized for URL unexpectedly ending in...".
La soluzione è aggiungere nel web.config le seguenti righe:

<system.web>

<webServices>

<protocols>

<add name="HttpGet"/>

<add name="HttpPost"/>

</protocols>

</webServices>

</system.web>

WebMatrix

Da oggi rilasciato tramite il web platform installer 3.0 è possibile testare il nuovo Microsoft WebMatrix un tool con cui è possibile scrivere siti web in modo semplificato. WebMatrix non sostituisce Visual Studio ma è pensato a chi vuole un approccio ancora più semplice.
Web Matrix sfrutta tutti gli ultimi tool rilasciati tra cui IIS Express, Sql Server CE 4 e Razor il nuovo motore di renderizzazione per le pagine asp.net mvc.