Mauricio Scheffer has just released a web based console for editing HQL. He based the intellisense on my project. I’m happy to see some of my effort reused somewhere! So thanks to Mauricio.

There is some interesting progress with my project Fatica.Labs.HqlEditor. I just want to share some screenshot:

Well, it is growing to be a real tool, and in my idea would became a sort of test bed in which the user can add or modify mapping, try the queries, change the config, export a database script, reverse engineering and so on. Actually all the low level tool to achieve that are available.

Ok, let’s explain the layout:

1. The document area, here we have mapping/config/hql all with intellisense. In the screenshot the code completion for an Hql is shown. In future maybe I will be able to insert a T4 editor for the hbm2net templates.
2. The project area: here we have a bounch of file that are representing our testing project: mapping, configurations, assemblies and so on. I have use the MSbuild object as a backend for the project, because in the near future I would like to use it to really build some artifacts using hbm2net and db2hbm.
3. Here is the SQL preview of the query in editing. Now the view is showing an error because the query is incomplete.
4. The funny log, a graphical appender for log4net

Some more words about the project itself: the testing environment is hosted in a separate appdomain, this will allow us to:

• Modify the mapping runtime generating new version of the assembly
• Testing production assemblies built with legacy nh versions ( well, not so legacy, starting from 2.xxx )

Let’s have another screenshot, showing a real SQL preview:

Next step is to produce the query results in some sort of usable representation ( I need to push the data across two app domain ) so I would probably use some JSON serialization and then display the JSON raw data with some readable formatting.

You can see a little demo video here.

The project is not yet released, please treat it as a CTP ;) anyway, the svn repository is here:

https://faticalabshqled.svn.sourceforge.net/svnroot/faticalabshqled

E’ da un po’ che in una certa realtà lo ripeto, ma non avevo mai trovato qualcosa di ufficiale a conforto. Adesso l’ho trovato.

In pratica vediamo perchè, scrivere l’interfaccia ICustomer sull’entità Customer sia sempre un errore. Sempre. Non in qualche caso. Perchè un entità non ha comportamenti. Un entità, per esempio “Customer” ritorna sempre la stessa cosa quando le si chiede, ad esempio, Name. Non c’è un algoritmo od una strategy che possa abbellire o rendere più intelligente il comportamento di Name. E’ poi interessante vedere come larchitettura diventa semplicemente oscena quando ICustomer ha per esempio un IAddress o qualsiasi altra reference…

Poichè è anche considerato un antipattern il Domain Model anemico ( cioè quello composto da sole entità  senza comportamenti) chi si ferma a leggere le prime righe di tutti gli articoli potrebbe pensare che piazzare su una bella interfaccia per ogni entità sia la soluzione. Questo non è però vero: vanno messi “dietro ad un interfaccia” i comportamenti che ha senso pensare che possano variare, ed eventualmente le entità potranno implementare una o più di queste interfacce di behavior. Per esempio Customer potrebbe implementare ICanPlaceHorder, e la logica con cui si piazza l’ordine potrebbe cambiare, ma le entità in gioco sono concrete.

Un interessante find storico sulla situazione è un caso pratico di Prima & Dopo.

Fabio Maulo sta proponendo una nuova astrategia di mapping per NHibernate: ConfORM. In pratica si tratta di una strategia code only, quindi nessun file di XML, ma tutto via codice con l’approccio fluent interface. Stranamente la community si è un po’ stupita di vedere un ennesima strategia, e tutti stanno lì a chiedersi il perchè. Bene, il perchè è che è una nuova possibilità di scelta, ed avere molte scelte è un plus degli ambienti open source. In un suo post Fabio disegna uno scenario completo della ricca rosa di partecipanti al problema mapping. Difatto ConfORM è l’unica API che sfonda completamente lo strato hbm, e va direttamente alla radice. Tutto questo si traduce immediatamente in un incremento di performance, ed in una migliore linearità progettuale: meno strati è meglio, anzi, meno strati inutili è meglio. Francamente, dopo una piccola esperienza acquisita nel problema mapping con la scrittura del tool NHModeller, ho deciso di tornare ed imparare la strategia HBM. Dopo un po’ non è così male, ma la prossima volta che faccio un progetto mio provo ad usarlo ( in azienda non se ne parla nemmeno: già il mapping XML è visto come una stregoneria, e c’è chi legifera che mappare le foreign Key come long sia una buona idea anzichè un antipattern ).

In conclusione: chissenefrega se un nuovo sistema sembra essere il duplicato di un altro:Vincerà il migliore, ed in ogni caso il migliore secondo gli utilizzatori

Uno scenario di possibile utilizzo di RemotingAppender è quando si voglia concentrare in un unico punto i log di più app domain hostati nello stesso processo. Infatti un app domain separato vede difatto un’altra configurazione di log4net e, se si volesse per esempio usare un appender su file, ci sarebbe una violazione di condivisione. Per cui RemotingAppender torna utile, consentendo di ribaltare il log di tutti gli app domain sul programma principale. Per prima cosa bisogna mettere il programma principale in grado di ricevere le chiamate di log via remoting. Supponiamo che MyLauncher sia la classe che avvia un processo in un AppDomain separato, potremmo scrivere:

class MyLauncher:MarshalByRefObject,log4net.Appender.RemotingAppender.IRemoteLoggingSink
{

E’ necessario che la classe derivi da MarshalByRef object, in quanto ne esporremo l’istanza via remoting. Deve altresì implementare IRemoteLoggingSink , per fungere da target per i messaggi di log4net.

A questo punto bisogna registrare il canale e l’istanza dell’oggetto atto a fare il sink dei messaggi:

   1:  private void PrepareRemotingLoggerListener()

   2:  {

   3:              var channel = new IpcChannel("log4net"+Guid.NewGuid().ToString());

   4:   

   5:              ChannelServices.RegisterChannel(channel, false);

   6:              var oref = RemotingServices.Marshal(this, null);

   7:              AppenderURI = channel.GetUrlsForUri(oref.URI)[0];

   8:  }

Supponiamo di chiamare il codice di sopra per ogni hosting di app domain. Il canale viene battezzato con una componente casuale, in modo da non entrare in conflitto con altre istanze dello stesso programma, o all’interno del medesimo processo se vi fossero più app domain esterni in esecuzione. Per registrare con remoting un istanza già creata si è usato RemotingServices.Marshal(---). Il codice memorizza in una proprietà AppenderURI: questo sarà l’indirizzo da usarsi con remoting appender per definire la proprietà Sink.In pratica è l’indirizzo remoting dell’oggetto “sink” dei messaggi.

Implementare IRemoteLoggingSink è facilissimo:

   1:          #region IRemoteLoggingSink Members

   2:   

   3:          public void LogEvents(log4net.Core.LoggingEvent[] events)

   4:          {

   5:              foreach (var le in events)

   6:                  logger.Logger.Log(le); // logger è un'istanza di 

//ILog nel programma principale, ottenuta con logManager.GetLogger...

   7:          }

   8:   

   9:          #endregion

In questo modo si ottiene un redirect di tutti i messaggi sul logger dell’applicazione principale, con filtri e appender come stabilito dalla configurazione dell’applicativo principale. I messaggi saranno accodati, quindi non ci saranno violazioni di condivisione anche con appender su file fisico.

Nell’app domain basterà configurare log4net in modo da utilizzare RemotingAppender. Il modo più facile è utilizzare BasicConfigurator:

   1:    BasicConfigurator.Configure(CreateAppender());

   2:    logger = LogManager.GetLogger("logger name");

CreateAppender si occuperà di creare il RemotingAppender in questo modo:

   1:          private IAppender CreateAppender()

   2:          {

   3:              RemotingAppender ra = new RemotingAppender();

   4:              ra.Layout = new log4net.Layout.SimpleLayout();

   5:              ra.Sink = LoggerURI; // Indirizzo del "sink"

   6:              ra.BufferSize = 512;

   7:              ra.Lossy = false;

   8:              ra.ActivateOptions(); // Ricordarsi di chiamare !!!

   9:              return ra;

  10:          }

Ed il gioco è fatto. LoggerUri è l’indirizzo dell’oggetto di sink ( vedi AppenderURI di prima ). BufferSize è il numero di messaggi da accodare prima di fare effettivamente la chiamata al canale: per ragioni di performance è meglio non abbassare troppo la soglia dei messaggi da raggruppare.

Finalmente, dopo tre anni passati con BlogEngine.NET, ho trovato il tempo di ritornare al fido DasBlog, secondo me il miglior blog engine con backend XML esistente. Ovviamente la causa del primo abbandono non era l’insoddisfazione, ma il fatto che Aruba, senza dire niente a nessuno, cambiasse da un momento all’altro le impostazioni del runtime .NET da full trust a medium trust. Per una serie di motivi DasBlog non era compatibile con tale modello, ma lo è stato in breve tempo. Nel contempo c’era blog engine .NET, che funzionava in medium trust, ma era povero e pieno di bachi. Dopo tre anni i bachi sono sempre gli stessi, per cui… meglio lasciare perdere. Per fare funzionare DasBlog su Aruba medium trust, tuttavia, bisogna dare qualche martellatina qua e la, perchè bisogna adattarsi alle meravigliose permission che hanno studiato i geniali sistemisti di Aruba, gli inventori di mdb-database, che nell’anno 2010 ci danno la gioia di usare un database access come nell’età della pietra… :)

Bene, come dicevo, con qualche martellatina ai sorgenti, si ottiene facilmente questo:

Tutto funzionante in medium trust, con le immagini che si inseriscono nella public, e i setting nella App-Data. Suggerisco di scaricare Windows Live Writer e attivate il nuovo account: Das Blog supporta il protocollo “Really Simple Discovery”, così collegarsi con live writer è un gioco da ragazzi, basta scegliere “altro blog engine”, inserire l’indirizzo del blog e la password, e fa tutto in automatico. Ovviamente se volete evitare di fare voi stessi le modifiche ai sorgenti di dasblog, potete scaricare la mia partch da qui. Prima di  copiare i file su Aruba, modificate il file site.config in app_data, in modo che il tag <root> punti alla directory del vostro blog ( nel mio caso http://www.felicepollano.com ), e già che ci siete, mettete anche uno user e password furbi per l’amministratore editando sitesecurity.config. fatto questo copiate pure i file via FTP, o con altri potenti mezzi che Aruba mette a disposizione, scegliete il tema, e avete finito.

E se… invece avete anche voi un altro engine in pista, e volete portare i vostri vecchi post su DasBlog ? Bene, io ho fatto così: Visto che il mio vecchio engine, bene o male, supportava le MetaWebLogAPI, ho scritto un piccolo tool command line per pompare i vecchi post sul nuovo motore. Ovviamente il nuovo motore l’ho installato momentaneamente in localhost, altrimenti come facevo ? ;) Il tool è assolutamente non user friendly, quindi se non avete voglia di dover mettere becco nei sorgenti lasciate pure perdere. In aggiunta, il tool usa una versione patchata della libreria metaweblog API di Pluralsight. La patch consiste nell’implementazione della funzione newMediaObject, non presente nella versione originale.