Crad's .NET Blog

Parlo di Cuyahoga, il noto CMS basato su Castle Windsor e NHibernate. Incuriosito da questo post di Ayende ieri ne ho spulciato un po' i sorgenti. E visto che li considero didatticamente interessanti, ve li consiglio.

Certo, non è da prendere tutto come oro colato (il modulo del Forum, ad esempio, espone tutti i servizi in una grande, enorme, monolitica classe, che accede direttamente a NHibernate, brrrrr...) però può essere una buona sorgente per qualche idea.

Tanto per dirne una, mi è piaciuta la strutturazione del Data Access Layer che sfrutta la "trasversalità" di NHibernate: IUserDao espone solo i servizi specifici dell'utente (es. Autenticazione, GetByUsername), mentre i servizi generici (GetById, ListAll, ecc.ecc.) sono forniti da ICommonDao, che però avrei preferito sfruttasse i generics.

Magari se non avete nulla di interessante da leggere nel vostro feed aggregator, dateci un'occhiata!

Posso anche essere d'accordo (anzi, lo sono decisamente) con Andrea e Dino, ma solo fintanto che li consideriamo come una sorta di guida all'implementazione. Allora sì che devo prendere spunto (giusto il paragone con le centurie), interpretandone il significato e adattandone però la struttura al mio problema specifico, magari disconstandomene fino ad avere un qualcosa di diverso. Che però non è più il pattern da cui sono partito.

Credo sia un concetto parecchio importante, e che richieda pertanto un certo rigore nelle definizioni e nel significato che si attribuisce loro. Perché? Perché i pattern hanno anche un'altra importante funzionalità, oltre quella di darci una traccia (più o meno aderente alla realtà) ad un problema ricorrente. Ossia quello di rappresentare *un dizionario*, un linguaggio che permetta a due progettisti di capirsi al volo quando parlano di un aspetto del design. E allora in questo caso la definizione dovrebbe essere precisa, talmente precisa da essere sicuri che se io propongo ad Andrea di soddisfare quel requisito tramite un Layer Supertype, o di utilizzare un DTO per esporre i dati all'esterno, o di gestire la persistenza tramite un Active Record (BUAHAH ecco che ci siamo), io e Andrea dobbiamo capirci al volo, senza nessun rischio di misunderstanding.

E allora dire che questo framework "è quasi un Active Record" mi fa storcere un po' il naso, perché o lo è o non lo è. Punto.

Tra l'altro, credo proprio che Linq To SQL sia un perfetto esempio di DataMapper, anzi, di MetaData Mapper, e che di Active Record non abbia proprio nulla. Perché, visto che citiamo Fowler, allora lui stesso descrive Active Record come

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

My two cents...

La cosa che più mi piace di ASP.NET AJAX non è il fin troppo abusato UpdatePanel (che pure i suoi bei meriti li ha tutti), bensì sbavo letteralmente per Microsoft AJAX Library, vale a dire quel popò di codice client che viene iniettato nelle pagine per

1. estendere Javascript con concetti tipo namespace, reflection, interfacce, and so on...
2. fornire un'infrastruttura per rendere quanto più possibile cross-browser il codice prodotto.

Esempio banale è la funzione $get, che ci permette di recuperare un'istanza di un elemento del DOM dato il suo id:

1 var myElement = $get('myElementId');

che non è nulla di trascendentale fintanto che la si usa per sostituire

1 var myElement = document.getElementById('myElementId');

ma che ad esempio diviene particolarmente comoda quando se ne usa l'overload

1 var myElement = $get('myElementId', 'parentElementId');

che ci permette di recuperare un element ispezionando solo un particolare ramo del DOM.

Altra chicca, per quanto mi riguarda, è il metodo $addHandler; il nome dice già tutto sulla funzionalità che implementa, ossia aggiungere un gestore ad un evento di un element, ma l'enorme vantaggio sta nel rendere cross-browser la signature e la logica dei gestori stessi:

1 $addHandler(myInput, "keypress", _myInputKeyPressHandler);
2 
3 function _myInputKeyPressHandler(args)
4 {
5     // ....
6 }

Quel parametro args è di tipo Sys.UI.DomEvent ed interrogandone il field "charCode", ad esempio, si potrà risalire al tasto premuto dall'utente, a prescindere dal fatto che questi stia utilizzando , IE, Firefox, Opera, ecc.ecc.ecc.