October 2007 - Posts
Di Acropolis ne avevamo già parlato durante TechEd 2007. Dopo alcuni mesi di silenzio, successivi alla presentazione a TechEd 2007, il team del prodotto ha annunciato che Acropolis farà parte di una delle versioni future di .NET Framework. Nel frattempo però non avremo nuove CTP ma solo un documento di Patterns & Practices, prima o poi disponibile, intanto teniamo d'occhio qui. Questa è una notizia importante per tutti coloro i quali devono scegliere se e come implementare la gestione della UI nelle loro applicazioni. Infatti se ad oggi si sviluppa su Windows Forms, si può decidere di valutare CAB (ma anche no :-) ...) mentre nell'ambito di WPF potrebbe essere Acropolis la linea guida da seguire. Mi auguro che resti valida anche l'idea, mostrata in fase di presentazione del progetto, di rendere utilizzabili dei workflow di WF per il controllo della UI. Staremo a vedere ...
Questa sera Igor ha segnalato nel suo blog che WSS3 sarà disponibile ancora come add-on separato, da scaricare e installare autonomamente, anche per Windows Server 2008. Giustamente ci si stupisce di questo fatto, ma d'altra parte stando a quanto ufficiosamente noto Windows Server 2008 monterà di serie solo .NET Framework 2.0, mentre .NET 3.0/SP1 sarà di serie solo sul Windows Server 2008 "App Server Role" e addirittura .NET Framework 3.5 sarà un update opzionale, via Windows Update.
Stando a queste notizie si capisce perché WSS3 non può essere presente di serie su Windows Server 2008, visto che richiede .NET 3.0 come requisito. Possiamo poi essere tutti assolutamente d'accordo sulla non opportunità di questa scelta :-), ma è un altro discorso.
Da notare anche il fatto che pare che su Windows Server 2008 Core by default non sia nemmeno installato il .NET Framework ... della serie "molto core", quasi troppo!
Ho letto ieri sera questo post di Dinesh Kulkarni, uno dei PM di LINQ to SQL. Trovo che sia molto interessante in quanto fornisce le motivazioni di alcune scelte prese nel disegno dell'architettura di LINQ to SQL e fornisce suggerimenti su quale sia il modo più corretto di utilizzarlo nelle applicazioni reali. In particolare trovo interessante il fatto che Dinesh evidenzi quelli che ad oggi sono ritenuti alcuni dei "limiti" di LINQ to SQL giustificandone il perché.
Quello che si evince è il fatto che LINQ to SQL è principalmente pensato per implementare il data layer, come spieghiamo da ormai parecchio tempo nei corsi e negli eventi su LINQ, oltre che nel libro su LINQ che ho scritto con Marco. Nei casi in cui, secondo me ormai rarissimi per non dire inesistenti, non dovesse servire un business layer si può pensare di usare LINQ to SQL direttamente dal presentation layer, per esempio con il LinqDataSource di ASP.NET 3.5. Quest'ultimo è uno scenario adatto a soluzioni "semplici" spesso prototipali. Secondo me in tutti gli altri casi servirà un business layer che si baserà su di un data layer sottostante astratto e creato tramite un factory. Il factory, nel caso di Microsoft SQL Server, potrà essere basato su LINQ to SQL, ma il tutto dovrà risultare trasparente ai layer superiori. Può invece risultare utile sfruttare le query LINQ ai vari livelli, sapendo che nel caso di adozione di LINQ to SQL queste potranno essere convertite in statement SQL generati da LINQ to SQL o in stored procedure ad hoc, a seconda dei casi.
Come si evince dal paragrafo precedente dissento un po' dall'idea di non implementare per nulla il business layer e utilizzare al suo posto dei partial method o delle partial class sul data model ottenuto dal DBML o da SQLMetal, come ipotizzato da Dinesh. Ritengo infatti che sia meglio disaccoppiare business layer e data layer, per avere sempre e comunque idipendenza dallo storage fisico, oltre a prevedere nel business layer tutte le logiche applicative, di sicurezza e di validazione. Avere una fusione a livello di data layer di questi concetti porterebbe ad essere vincolati ad un unico motore DBMS, aspetto che di solito trovo limitante nell'architettura delle soluzioni software moderne.
Ultime note da rilevare sono la considerazione sul fatto che il DataContext e il framework di entità generate da LINQ to SQL, in una delle possibili modalità (SQLMetal o DBML da designer), sono pensati per essere leggeri. Ho notato anche io nei miei test e nelle mie prove che è sensato, in scenari distribuiti e/o fortemente disaccoppiati, come servizi SOAP o pagine ASP.NET 3.5, sfruttare DataContext dedicati ad operazioni atomiche, piuttosto che creare un unico DataContext condiviso a livello di Application Domain. D'altra parte i metodi di Attach e lo stato di detached sulle entità servono anche per questi scenari. Anche gli esempi forniti da Scott Guthrie sono molto chiari ed evidenti in questo senso.
Ormai ci siamo quasi ... non vedo l'ora che sia disponibile .NET 3.5 in versione RTM così da poterlo integrare e "misurare" in alcune soluzioni.
Sempre più spesso mi trovo a consigliare ai clienti l'adozione di WSS3 o MOSS2007 non solo come strumento fine a se stesso, ma proprio ragionando sul concetto di "SharePoint = Punto di condivisione", usarlo come punto di contatto tra le varie soluzioni implementate all'interno dell'azienda.
Questo post evidenzia con uno schema logico abbastanza chiaro quale potrebbe essere l'idea: usare SharePoint per consumere servizi SOA trattando l'XML ottenuto con gli strumenti e le WebPart che MOSS/WSS offrono.
SharePoint è proprio questo: uno strumento per condividere tutto e per unire i vari ambiti applicativi di un'azienda. Di per sé un portale MOSS/WSS non serve a nulla se non lo integriamo con risorse, applicazioni e servizi terzi e infatti in tutti quei casi in cui è utilizzato solo come "prodotto" e non come "strumento di integrazione", spesso poi il progetto non approda a nulla di veramente utile, di fatto non raggiungendo l'obiettivo che ci si era dati.
Questa è una di quelle notizie destinate a fare "il botto". Dal blog di ScottGu, in un post di oggi, si legge che Microsoft renderà disponibili i sorgenti di .NET 3.5.
In particolare si inizierà con la BCL per poi passare anche a WCF, WF, LINQ, ecc.
Davvero molto interessante poi la possibilità di fare debug fino al livello dei sorgenti del Framework, sfruttando un repositori remoto (presso Microsoft) dei simboli.