arguros wrote:
Grazie per avermi risposto.
Faccio riferimento al programma scritto da Riccardo Golia e disponibile come allegato in Tutorial -> Architettura -> Archidettura del Software: Le applicazioni web a tre livelli.
ok, quindi ASP.NET e non ASP. sposto la discussione nel forum corretto.
Ieri notte sono riuscito a fare una mappatura UML del programma (ci ho messo 4 ore) e ho un'idea molto piu' chiara di come funzioni. Se vuoi posso spedirti il file a un indirizzo di posta elettronica se puo' aiutarti a capire la struttura dello stesso.
contatta direttamente Riccardo, anche se in questo periodo è in ferie
al ritorno ti risponderà.
1) Ma se voglio implementare metodi piu' specifici, cosa devo fare? Estendere L'interfaccia IService<T> e definirne un altra del tipo IBookSerive<T> where T : Book? Introdurli nel BookService direttamente senza metterli nell interfaccia? o implementarli direttamente nel oggetto Books?
dipende, come sempre in questi casi. io opterei per un'interfaccia specializzata, così da poter controllarne meglio il contratto, ma tutte le altre ipotesi che fai sono lecite. bisogna vedere se ti interessa tenere un forte disaccoppiamento o meno.
2) L'Autore implementa alcuni Filtri sulla CollezioneBooks. Ma per funzionare fa una cosa del tipo
BookService.ReadAll().FilterByPublisher.
Se abbiamo un milione di libri in memoria, non mi sempra ottimale caricarli tutti in memoria per poi filtrali.
ovviamente questo è un esempio di come deve essere fatta l'architettura, non l'implementazione. in uno scenario reale quei filtri lavorano direttamente con il servizio/data layer per farsi dare esattamente i dati che servono. a meno che di mezzo non ci sia un sistema di cache distribuita, ad esempio
insomma, questi sono dettagli implementativi che variano in base allo scenario applicativo in cui ti trovi. e questo è un esempio di come strutturare l'applicazione.
3) Qual'e' l'idea di base che IService<T>?
quella di offrire una interfaccia comune ai servizi.
Ti ringrazio per l'aiuto.
prego.