Componente != Servizio
Credo che in generale ci sia un problema di fondo nella teminologia usata: quando si parla di IoC si usa indifferentemente componente o servizio. L’errore secondo me sta nell’utilizzare poi indifferentemente servizio quando questo viene inteso come componente e quando questo invece viene inteso come servizio nel senso SOA del temine, portando alla convinzione che siano concettualmente utilizzabili allo stesso modo.
Secondo me non c’è nulla di più sbagliato, ho la ferma convinzione che il codice debba esplicitare, e non nascondere, che si sta utilizzando un servizio nel senso SOA del temine perchè l’approccio da utilizzare e le problematiche da gestire e prendere in considerazione sono abissalmente diverse.
Secondo me è un grave errore pensare che la differenza tra n-layer e n-tier stia solo nel fatto che il boundary è diverso. Non è possibile pensare di scrivere uin’applicazione n-layer e migrarla a n-tier piazzando un po’ qua e un po’ la Wcf e una facility per Castle.Pensate a questo scenario:
IDataContextFactory è un wrapper per la session factory di NHibernate, nulla di trascendentale, il codice esplicita molto bene quello che succede. La IDataContextFactory viene iniettata con Castle Windsor. Adesso immaginamo che:using( var dc = this.dataContextFactory.Create() ) { using( var tx = dc.BegingTransaction( IsolationLevel.Serializable ) ) { dc.Insert( entity ); dc.FlushChanges(); tx.Commit(); } }
- Qualcuno scrive una nuova implementazione di IDataContextFactory e IDataContext che utilizzano Wcf;
- Qualcuno modifica il file di configurazione di Castle per utilizzare la nuova implementazione e la WcfFacility;
- Qualcuno configura Wcf per utilizzare Message Queue;
Cosa succede se il servizio Wcf è giù?
.m