OO design, domain objects e presentation layer

April 19 2006

Eccomi di nuovo qui a snocciolare i dettagli e le infinite problematiche di un’applicazione reale. Non basta per sentirsi “al sicuro” l’aver con fatica imparato a strutturare i vari livelli seguendo tutti i principi di buona progettazione che riesci a ricordare a memoria! E nemmeno essere riusciti ad incollare in un’unica soluzione tecnologie “Off the Shelf” come OR mapper e container per l’IoC. Insomma… ecco il quesito.

Mi trovo per l’ennesima volta a riaffrontare costi e benefici legati alle varie soluzioni (che conosco) per la comunicazione tra business layer e strato della presentazione (in corsivo, perchè mi viene sempre da sorridere quando mi immagino oggetti software in carne ed ossa che assumo sembianze umane, di magnati del commercio incravattati e con doveroso sigaro in bocca mentre illustrano grafici di andamento delle azioni… sì, ho qualche problema).

L’architettura (la stessa di cui ho parlato fino ad ora nei miei post) è fatta così: uno strato di oggetti controllori dell’applicazione (che realizzano le regole dei vari casi d’uso), che lavorano su oggetti del dominio (un assembly privo di dipendenze, se non verso la libreria di validazione), mentre la persistenza è gestita da uno strato data access (wrapper di NHibernate). Questo per quanto riguarda la parte applicativa. I problemi iniziano quando invece ci affacciamo verso “il cliente”, e parliamo di presentazione.

I client degli strati sopra descritti, o meglio, dello strato dell’applicazione, sono una serie di oggetti dell’interfaccia utente: l’unica supposizione che faccio è che questi oggetti siano locali rispetto all’esecuzione delle librerie business. Per locali intendo eseguiti sulla stessa macchina e nello stesso processo. I due esempi che ho (e che realmente utilizzo) sono pagine ASP.NET e casi di test di NUnit. Quindi niente accesso remoto. Questa considerazione mi servirà in seguito come ulteriore metro di giudizio.

Ho fatto in modo che l’accesso allo strato applicativo avvenga attraverso interfacce: un factory concreto (come BusinessFactory) a cui richiedere l’instanziazione dei controllori, definiti in termini di interfacce (ad esempio BusinessFactory.CreateHandler() che ritorna un oggetto di tipo IHandler). Quindi l’unico punto di accesso per le istanze dei vari handler è il factory concreto, che riesco a “rendere indipendente dall’applicazione” e quindi riutilizzabile grazie al container IoC (incapsulato dentro il factory). Il bello è che quindi posso riusare lo stesso client – la UI, come un itero sito web – senza ricompilare, e pluggare le regole di business da file di configurazione, specificando l’assembly con i controllori concreti. Molto elegante.

Ecco finalmente il punto chiave (e visto che da il titolo al post direi che è ora di affrontarlo!).

Come gestire la comunicazione nei due sensi tra:

  • UI >> Business >> Domain
  • Domain >> Business >> UI

Il punto cardine è che non voglio dare ai client – UI – accesso diretto alle funzionalità offerte dagli oggetti domain (metodi e setter). Il motivo è semplice: non voglio pormi il problema di un “cattivo utilizzo” da parte dei client, e fare in modo invece che tutte le modifiche avvengano tramite i controllori dell’applicazione.

Per ora ho risolto così (chiamiamola prima idea): per gli oggetti del dominio che richiedono di essere “visti” nella  UI, definisco un insieme di interfacce con un numero ridotto di properties (in sola lettura), e nessun metodo, corrispondenti alle cartteristiche che voglio rendere visibili. Le classi concrete del domain model implementano tali interfacce (che risultano quindi un sottoinsieme dell’interfaccia – l’elenco metodi – dichiarata nelle classi domain).

Tutta l’attività dei controllori è svolta in termini di queste interfacce: parametri dei metodi e tipi di ritorno. La conversione tra oggetti dominio e interfacce (Business >> UI) è gratuita grazie al Liskov Sostitution Principle (o chiamiamolo come si deve: progettazione rivolti alle interfacce!). La conversione inversa invece, Business >> Domain, avviene con un cast (o con un Find(objName) quando l’oggetto è “vicino” nell’albero della gerarchia degli oggetti – magari dopo spiego meglio).

La soluzione corrente non mi dispiace troppo, ma è comunque molto vincolante, non tanto per quanto riguarda il cast (anche se rende impossibile testare i controllori con oggetti Mock generati partendo dalle interfacce), ma per un altro problema molto più fastidioso: la dichiarazione delle interfacce degli oggetti del domain.

Infatti, per fare in modo che sia davvero utile tutta questa complessità (utile nel senso che mi porta un vantaggio rispetto al dare ai client – UI – accesso diretto agli oggetti del dominio) devo garantire che tutte le proprietà dichiarate nelle interfacce siano o di tipo primitivo (stringhe, interi, etc.) o altre interfacce del domain. E questo non è sempre possibile.

Quest’ultimo discorso potrebbe far venire in mente una soluzione analoga, per la quale cioè possono fare le stesse considerazioni (la seconda idea): usare i Data Transfer Objects. Parolaccia!

Non mi dilungo, visto che c’è un sacco di documentazione in rete. Arrivo direttamente al punto: non mi piace e non mi serve. Ricordate la premessa fatta all’inizio del post riguardo l’esecuzione locale del processo client e dei moduli business? Fowler spiega bene come i DTOs perdano valore in questo contesto, li chiama Local DTOs.
[a dimostrazione che non esistono soluzioni buone sempre… ma se qui risulta inapplicabile poichè cade la premessa fondamentale, per lo strato business remoto, incastonato in webservices, torna invece in auge].

Oggi pomeriggio ho provato a pensare se esiste una terza idea: in sostanza però ho cercato qualche workaround lessicale del C# per fare in modo di superare l’ostacolo che non mi permette di ridefinire il tipo di una proprietà (da interfaccia a oggetto domain). Non ho avuto troppo successo.

E qui entrate in ballo voi! Sono tutt’orecchi.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: