Bit a bit, si cresce sempre


Blog di un ingeformatico
Statistiche
  • Views Home Page: 489.350
  • Views Posts: 1.565.806
  • Views Gallerie: 738.786
  • n° Posts: 520
  • n° Commenti: 301
Ora e Data
Archivio Posts
Anno 2017

Anno 2016

Anno 2015

Anno 2014

Anno 2013

Anno 2012

Anno 2011

Anno 2010

Anno 2009

Anno 2008

Anno 2007

Anno 2006

Anno 2005

Recensione libro Microsoft .NET: Architecting Applications for the Enterprise (Microsoft Press)

Libri sull’architettura del software non mancano, ma se si applica la “where” dove la piattaforma è il .NET Framework, il linguaggio usato C#, e l’ambiente sono le applicazioni di classe “Enterprise”, ecco allora che la lista si riduce di almeno un ordine di grandezza. Se poi si mette anche un “AND” richiedendo autori italiani, penso che il risultato sia uno solo, questo libro.

Una premessa: qua si parla di architettura di sistemi, e malgrado ci siano comunque un buon numero di esempi in C#, il discorso non verte sulle funzionalità del linguaggi (o ne mette in luce aspetti più reconditi), ma la trattazione è molto più di alto livello, tant’è che si basa molto sulle “bibbie” di Martin Fowler, il guru degli architetti software, le cui opere sono più volte citate lungo durante i discorsi (soprattutto il “Patterns of Enterprise Application Architecture”).

 

Il libro è suddiviso in due parti, per un totale di soli 7 corposi capitoli (soprattutto gli ultimi 4 sono decisamente lunghi e impegnativi).

La prima parte (i primi 3 capitoli) va letta necessariamente, dato che è la base su cui si costruisce il resto del libro. Se proprio si è esperti di UML, al massimo, si può saltare il secondo, ma lo sconsiglierei comunque, fosse solo per le perle di saggezza che gli autori disseminano qua e là per tutte le pagine.

 

Nel primo capitolo, molto discorsivo, si ripercorre la storia e il significato (che si è modificato man mano negli anni) dell’essere “architetto” nell’industria del software. Si spiegano le due filosofie in qualche modo contrapposte, ovvero di tipo “Waterfall”, la tradizionale, e le metodologie “agili”, ovvero l’Extreme Programming (XP) e la Scrum.

Cosa differenzia un architetto da un analista?

Cosa differenzia un architetto da uno sviluppatore?

Di cosa si dovrebbe occupare e cosa invece dovrebbe delegare?

Come ci si approccia ad un progetto software che sta per partire?

Quali sono i pattern più utilizzati e cosa li differenzia uno dall’altro?

A queste, e molte altre, domande, risponde appunto il capitolo 1.

 

L’inglese molto leggibile e la prosa, in certi passi anche divertente ed ironica, consigliano di non saltare questo capitolo introduttivo, che fa da preludio per tutto il resto del libro.

Simpatica la metafora degli architetti come personaggi che vivono in lussuosi attici, giocano a golf e non si “sporcano” le mani con il codice, rispetto ai “sottoposti” sviluppatori, che vivono ai piani bassi e non giocano di certo a golf (tennis per Dino Esposito e squash per Saltarello, giusto come curiosità).

Per ora di codice non ce n’è; se ne parla, ovviamente, ma lo si rimanda per il proseguo.

 

Il secondo capitolo introduce quei pochi concetti basilari di UML che serviranno per affrontare i successivi capitoli. Se esiste un argomento arido e difficile da far digerire a studenti a digiuno (gioco di parole non voluto) di linguaggi di modellazione, è proprio l’UML. Gli autori, complice il tono molto discorsivo ed informale, ricco anche di aneddoti vari e curiosi, riescono a far apprezzare ed assimilare i concetti base.

Da questo capitolo si iniziano a vedere piccoli pezzetti di codice; il linguaggio utilizzato nel libro è C#, come detto.

 

Il terzo capitolo, molto più lungo (63 pagine) inizia ad introdurre i vari pattern che un architetto può disporre nel proprio arsenale. Si parla anche di test (utilizzando quelli intrinseci di Visual Studio 2008, quindi niente tool esterni tipo NUnit) e sicurezza del codice. Questo capitolo fa da punto di partenza per i restanti quattro (sono solo 7 i capitoli totali del libro), e la sua lettura (e magari rilettura) assume una certa importanza.

Se proprio devo muovere un appunto, magari non avrei esagerato nel mettere troppa carne al fuoco. Alcune metodologie (OCP – Open/Close Principle, LSP – Liskov Substituition Principle, DIP – Dependency Inversion Principle, ecc.) davvero poco conosciute ed utilizzate. Ma forse l’idea degli autori era anche di esporre uno stato dell’arte il più possibile a 360 gradi.

Il capitolo però si chiude bene, e a pag. 124 riassume in tre punti delle idee che dovrebbero sempre costituire capisaldi imprescindibili. Le riporto perché vale la pena:

 

·         Don’t Repeat Youself (DRY) – Refers to reducing duplication of any information needed by the application, and suggests you store the same information only in one place.

·         Once and Only Once (OAOO) – Refers to reducing the number of times you write the code that accomplishes a given operation within an application.

·         You Aren’t Gonna Need It (YAGNI) – Refers to adding any functionality to an application only when it proves absolutely necessary and unavoidable.

 

Dal quarto capitolo in poi, ovvero gli ultimi quattro capitoli, si entra nel vivo del discorso, analizzando i 4 livelli software in cui si esplica l’attività di un architetto, ovvero:

 

-        Business Layer

-        Service Layer

-        Data Access Layer

-        Presentation Layer

 

Si iniziano le danze con il Business Layer, la parte più importante di un’architettura software (gli autori seguono un ordine in base all’importanza del layer). In 64 pagine, dopo una lunga ma necessaria introduzione,  si spiegano nei dettagli 4 tipologie di pattern: Transaction Script, Table Module, Active Record e Domani Model. Gran parte dei discorsi prendono spunto dal libro di Martin Fowler, “Patterns of Enterprise Application Architecture” (Addison-Wesley, 2002), considerato la bibbia sull’argomento. Di esso vengono riportati alcuni diagrammi e figure.

 

Una caratteristica che non avevo mai notato in nessun altro libro, è che ogni capitolo termina con un breve paragrafo riportante alcune leggi di Murphy adattate al contesto del capitolo stesso: sono molto ironiche e direi anche azzeccate.

Rientrano invece maggiormente nella consuetudine le frasi famose, dette o scritte da importanti personaggi non solo informatici, che precedono l’inizio di ogni capitolo.

 

La rilegatura è molto flessibile, la carta non lucida e piacevole al tatto, e l’impaginazione complessiva è ottima.

Il libro quindi, considerate anche le dimensioni non eccessive, si fa maneggiare con piacevolezza.

Unica accortezza, se viene usato parecchio, tende ad “aprirsi” facendo staccare le pagine.

 

Personalmente, quando ricevetti questo libro (nella primavera quest’anno), pensavo di terminarne la lettura in un mesetto di letture serali. Per leggere 400 pagine non ci vorrà mica un’eternità, pensai.

Invece ci ho messo 6 mesi; non avevo messo in conto il fatto che ogni pagina è “pregna” di concetti, come anche di testo (lo spazio bianco infatti è ben poco). È anche vero che leggo sempre 2 o 3 libri in contemporanea, ma questo è un altro discorso.

 

Il codice sorgente può essere recuperato a questo link dove sono riportate le istruzione per il download del progetto NSK (Northwind Starter Kit).

Credo però che se un lettore ha stretto bisogno del (poco) codice sorgente di questo libro, in realtà ha sbagliato acquisto. Questo non un testo per imparare come scrivere codice, e questo vale anche per altri libri che trattano il medesimo argomento. Qualche esempietto ci sta, qua e là, per chiarire un attimo il discorso, ma il “vero” lettore di tali libri si crea già nella sua mente delle mappe su come poi strutturerà il proprio codice.

E per questo motivo mi lasciano un po’ perplesso alcune critiche mosse a questo libro su Amazon, dove alcuni lettori lamentano proprio la scarsezza di esempi. In realtà hanno completamente sbagliato ad acquistarlo; comincino prima a studiarsi per bene dei libri avanzati su C# (Richter o Troelsen, ad esempio), e poi passino a questo. Si accorgeranno che non sentiranno poi così tanto la mancanza di esempi.

 

 

PRO

Questo libro da solo costituisce un “pattern” su come si strutturano le applicazioni di livello enterprise con il .NET framework, e delle varie soluzioni se ne spiegano i pro e i contro. Con la consueta verve di scrittura di Dino Esposito, si ha lo stato dell’arte sull’argomento. Interessante l’idea delle “Murpy's law of the Chapter” poste alla fine di ogni capitolo.

 

CONTRO

La strutturazione con lunghissimi capitoli (soprattutto nella seconda parte) non aiuta nell’apprendimento, come anche entrare in dettagli di puro contorno. Date le numerosissime sigle riportate nel testo, sarebbe stato utile un glossario finale che le esplicasse nel loro significato. Rilegatura flessibile ma troppo delicata.

 

 

Voto complessivo: 8/10

 

Lettore: Tutti gli sviluppatori di software con una discreta esperienza

 

 

Table of Contents

Introduction

Part 1 – Principles

3 – Cap. 1: Architects and Architecture today

31 – Cap. 2: UML Essentials

63 – Cap. 3: Design Principles and Patterns

Part 2 – Design of the System

129 – Cap. 4: The Business Layer

193 – Cap. 5: The Service Layer

251 – Cap. 6: The Data Access Layer

343 – Cap. 7: The Presentation Layer

401 – Final Thoughts

405 – Appendix: The Northwind Starter Kit

413 – Index

 

 

Titolo: Microsoft .NET: Architecting Applications for the Enterprise
Autori: Dino Esposito, Andrea Saltarello
Editore: Microsoft Press
ISBN: 9780735626096
Pagine: 433
Prezzo: 44.99 $ (prezzo di copertina)
Data di uscita: 15/10/2008

Categoria: Books
giovedì, 01 ott 2009 Ore. 10.31

Messaggi collegati


Meteo
Copyright © 2002-2007 - Blogs 2.0
dotNetHell.it | Home Page Blogs
ASP.NET 2.0 Windows 2003