<< [OT] Sulla censura in internet | Home | Architettura, una visione moderna >>

Architettura: Inversion of dependency dal data layer in su

Questo articolo di MS descrive 4 modi di rappresentare le entità da persistere sul db e farle fluire tra i vari strati:

  1. valori scalari
  2. xml senza xsd e poi con xsd
  3. dataset/datatable con inverion of dipendency
    1. non tipizzati
    2. tipizzati
  4. entità di business
    1. non crud con inverion of dipendency
    2. crud (non preferibili alla non-crud)

descrivendo come in base alla situazione scegliere una rappresentazione o l'altra: Progettazione di componenti per l'accesso ai dati e passaggio dei dati da un livello all'altro.

In molti progetti ho trovato le soluzioni 3 e 4.1 adatte (e a volte la 2 e in piccoli ambiti la 1) permettendomi di evitare i costi e la complessità che ha la 4.2. Il principio di inversione delle dipendenze ha il grosso vantaggio di eliminare dipendenze inutili che aumentano lo sforzo nel scrive il codice e modificarlo.

Anche la soluzione mista 3 + 4 mi ha dato molti vantaggi in semplicità, tempo e qualità.

Quando la 4.2 sembra l'ottimale (occhio che l'abitudine porta a preferirla anche per i progetti in cui le 3 e 4 sono preferibili) è il momento di ... lasciar perdere la 4.2 e iniziare a pensare soluzioni ORM come NHibernate facendo due chiacchere con Janky.

 

 

Link di approfondimento:

 

Print | posted @ sabato 11 novembre 2006 15:23

Comments on this entry:

Gravatar # re: Architettura: Inversion of dependency dal data layer in su
by Michele Bersani at 11/11/2006 16:25
Sono d'accordo.
Il pensare di scriversi oggi un framework per implementare la 4.2 e', come giustamente dici tu, sconsigliato... considerando quanti tools ci sono che permettono di implementare la funzionalita' in una frazione del tempo.
Comments have been closed on this topic.