MesBlog

Thinking in sharp architectures
posts - 179, comments - 436, trackbacks - 150

Factory Pattern

Esiste un dubbio atavico circa l'implementazione pratica del Factory Pattern. In genere, anzi praticamente sempre, nei file di configurazione delle nostre applicazioni inseriamo sia il riferimento all'assembly che contiene la classe factory, sia il riferimento all'assembly che contiene la classe oggetto di factory,  (insomma quella di cui alla fine ci serve l'istanza e che useremo nella BL), nonchè il suo nome.
Ma mi domando una cosa di questo tipo: a me piacerebbe davvero tanto che nel file di configurazione comparisse solo e soltanto il riferimento all'assembly della classe factory, in modo da non avere alcun legame fra l'applicazione e il modo in cui la classe factory ritorna l'istanza della classe da fattorizzare.
è praticamente scontato che nel momento in cui indico anche l'assembly della classe da fattorizzare so anche già il metodo che userà la factory per accedere al riferimento dell'oggetto di istanza per poi tornarmelo: reflection. Ed in fondo questo va bene nel momento in cui questo pattern mi permette di poter cambiare entrambi gli assembly in qualsiasi momento senza toccare un riga di codice che sia una.

Ma se volessimo spingerci più in là? Ad esempio non volere in alcun modo dare idea alcuna di come la factory accede al riferimento dell'oggetto di istanza?
Penso al caso in cui una soluzione applicativa nelle sue prime release utilizza reflection per istanziare tramite factory l'oggetto di istanza, poi, nelle release successive all'aumentare della complessità del sistema e magari per ragioni di scalabilità, le stesse funzionalità (interfacce) vengono trasferite su un servizio di windows. In questo caso l'accesso tramite factory non può più essere fatto via reflection di un assembly con la classica CreateInstance, ma deve essere fatto via remoting agganciandosi all'unico oggetto che viene creato al momento dello start del servizio. In questo caso dovremmo anche cambiare la struttura del file di configurazione dell'applicazione client in quanto non servono più i riferimenti all'assembly e al nome della classe da fattorizzare, bensì ad esempio l'url in cui è stato "marshalizzato" l'oggetto dal servizio windows.
A mio modo di vedere questo incide sull'applicazione client, poco è vero, nel senso che incide solo su un miserrimo file di configurazione xml che modifico in due secondi con notepad, ma in line di principio incide.

Invece mi piacerebbe una soluzione in cui nemmeno questo serve, che so la possibilità di avere un app.config nativo anche per le dll (che ad oggi .NET non prevede): storco un po' la bocca all'eventualità di un file di configurazione custom per l'assembly della factory, ma forse è davvero l'unica soluzione.

O mi sbaglio?

saluti

powered by IMHO 1.2

Print | posted on giovedì 17 febbraio 2005 17:11 |

Feedback

Gravatar

# re: Factory Pattern

ti si è "allargata" la barra di sinistra, ora copre i post...
17/02/2005 17:58 | Lorenzo Barbieri
Gravatar

# re: Factory Pattern

ok... risolto ;-)
17/02/2005 17:58 | Lorenzo Barbieri
Gravatar

# re: Factory Pattern

Esperimenti con l'interfaccia admin di .Text.... :-)
17/02/2005 18:02 | Roberto Messora
Gravatar

# RE: Factory Pattern

Esatto, ma quello che a me non piace è mettere i riferimenti di ciò che necessita la factory per fare il suo lavoro nel config del client che richiama la factory.
In giro ho visto molto poco spesso l'uso di custom config legati ad una library (dll).
Nel progetto che sto seguendo attualmente mi sono creato un CustomConfigurationSettings che mi permette di leggere le configurazioni di una library dal proprio file di config. In pratica se ho un assembly pippo.dll gli associo un file di configurazione pippo.dll.config (che però purtroppo devo mettere a mano da VS.NET che notoriamente non supporta i file di configurazione per le library).
Il mio intento è quello di uno scenario di deploy in cui nel file di configurazione dell'applicazione client compaiono solo i riferimenti al nome dell'assembly e della classe factory, quello che andrò a fornire all'applicazione sarà sia l'assembly che il suo file di configurazione.
ovviamente sia l'applicazione client che la classe factory avranno il riferimento all'assembly condiviso delle interfacce comuni.
saluti
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET