Mi sono imbattuto in questo link che racconta una "storia vissuta" relativa a NServiceBus:
http://www.make-awesome.com/2011/02/my-nservicebus-moment-of-bliss/
In questi giorni sto utilizzando una funzionalità piuttosto interessante di NHibernate, ovvero la possibilità di mappare un domain model "dinamico" tramite
dynamic-component.
Questa funzionalità permette di mappare in modo speciale alcune colonne di una tabella di un entità, infatti al posto di utilizzarle come singole proprietà vengono inserite in un dictionary (possono essere sia tipo semplici che vere e proprie entity).
Qui un link che mostra il funzionamento :
http://ayende.com/Blog/archive/2009/04/11/nhibernate-mapping-ltdynamic-componentgt.aspx
Qui invece un link che mostra come modificare la configurazione senza agire sul file di mapping, ma editando "on-the-fly" prima che la session-factory venga creata:
http://www.junasoftware.com/blog/custom-domain-using-nhibernate-dynamic-component.aspx
Ad un primo sguardo può sembrare un comportamento particolare, ma può venire in aiuto quando si gestisce un sistema "modulare" dove uno dei requisiti è quello di creare plugin indipententi fra di loro, senza agire sul "core" del sistema.
In questo modo ci è possibile estendere una entity aggiungendo delle proprietà custom che non sono conosciute all'interno del modulo base, ma vengono gestite unicamente nel plugin dedicato.
Navigando mi sono imbattuto in questo link :
http://microsoftnlayerapp.codeplex.com/.
Riprendo direttamente dalla descrizione del progetto :
Domain Oriented N-Layered .NET 4.0 Sample App.
By Microsoft - Spain
Using .NET 4.0 C#, Entity Framework 4.0
Implementing typical DDD architecture & desing patternsEccomi qua, dopo il post di
Mario direi che c'è poco da aggiungere :)
Finalmente sono aperte le iscrizioni al
primo evento della DotNetteria....si lo so, i posti non sono molti, ma siamo davvero molto contenti dell'evento e delle sessioni che lo compongono! Io in prima persona sarò spettatore interessato, in quanto sono sempre stato "affascinato" da Silverlight.
Non posso fare altro che ringraziare tutti quelli che hanno partecipato alle fasi organizzative e che prenderanno parte all'evento.
Allora ci si vede lì? :)
Negli ultimi periodi è emersa una problematica nell'import o commit di diversi file in repositories svn (soprattutto su grosse quantità).
Dopo alcune ricerche abbiamo riscontrato la stessa problematica in alcuni utilizzatori di AVG. L'unica soluzione che abbiamo trovato per risolvere la problematica è stata quella di escludere la cartella del repository dal resident shield di AVG e tutto ha ripreso a funzionare (con un discreto aumento di prestazioni).
Riporto qui un paio di link :
http://russtaylor.co.uk/2009/12/error-when-importing-to-subversion-repository-the-requested-operation-cannot-be-performed-on-a-file-with-a-user-mapped-section-open/
http://stackoverflow.com/questions/2182822/how-to-change-from-https-to-svn-protocol-in-subversion-server
Ovviamente ogni altra soluzione / consiglio è ben accetto :)
Mentre stavo attuando una risistemazione di alcuni repositories SNV mi sono imbattuto in questo articolo (non proprio "nuovo" lo ammetto
) che spiega in maniera abbastanza semplice come gestire gli externals nei repositories svn e di come questa può essere una soluzione per le referenze dei progetti:
http://arcware.net/using-svn-externals-to-manage-project-references/Una delle problematiche frequenti che ho incontrato nella stesura di domain model complessi è l'utilizzo di servizi di dominio all'interno di entità. Tra le varie possibilità ho trovato in rete e sperimentato tre diverse soluzioni:
- Service locator statico : crea non poche problematiche (vedi unit test)..personalmente da evitare
- Risoluzione delle dipendenze delle entità tramite DI : utilizzando per esempio NHibernate risulta piuttosto semplice risolvere la problematica usando un session interceptor
- Double dispatch : risulta di facile implementazione e il codice è immediatamente comprensibile
Riporto qui due link che parlano dell'ultima casistica:
Ovviamente queste sono considerazioni personali, ma sarei curioso di capire come tematiche di questo tipo vengono affronate quotidianamente (è molto facile in rete trovare esempi relativi a DDD legati a realtà più o meno semplici, ma casistiche complesse e più "reali" sono molto rare).
Un mio collega mi ha segnalato questo interessante link ad un tool che semplifica la gestione, i caricamenti in parallelo e le dipendenze tra i vari js :
http://labjs.com
Dopo aver superato i piccoli problemi tecnici che mi impedivano di "postare" (grazie al buon
Andrea) eccomi nuovamente operativo
.
Ecco una casistica che abbiamo affrontato ultimamente all'interno del team di sviluppo, ovvero l'utilizzo di cache di 2° livello e connessione manuale con NHibernate (purtroppo utilizziamo ancora la 1.2.1).
Come da post del buon
Ayende, nel momento in cui si utilizza una connesione manuale la cache di 2° livello non funziona più correttamente. Dopo le prime ricerche siamo giunti alla soluzione che utilizziamo attualmente, ovvero realizzare un
ConnectionProvider personalizzato.
Nel nostro caso abbiamo bisogno di utilizzare la connessione ad un DB A o un DB B in base a delle particolari condizioni (ovviamente sono strutture identitche) e quindi abbiamo realizzato una soluzione di questo tipo (prendete con le molle lo "pseudocodice") :
public class CustomConnectionDriver : NHibernate.Connection.ConnectionProvider
{
public override IDbConnection GetConnection()
{
IDbConnection currentConnection;
//Selezione della connessione in base ai criteri
if (....)
{
currentConnection = ConnessioneA;
}
else
{
currentConnection = ConnessioneB;
}
currentConnection.Open();
return currentConnection;
}
}
Successivamente andrà configurato nel file di NHibernate il nostro nuovo connection provider:
<property name="connection.provider">CustomConnectionDriver </property>
Ora basta avviare il progetto e provare a verificare il corretto funzionamento della cache di 2° livello.
Dopo un piccolo periodo di assenza ho deciso di postare alcune parti di codice per la realizzazione di una WebPartChrome custom (anche in seguito alla richiesta da parte di un lettore del blog ).
Nel mio caso ho dovuto realizzare delle webparts con un look&feel completamente custom e questo porta alla necessità di realizzare un WebPartChrome, il quale si occupa del rendering vero e proprio.
Quindi realizziamo la nostra classe MyWebPartChrome che eredita direttamente da WebPartChrome e andiamo a fare l'override del metodo RenderWebPart :
public class MyWebPartChrome : WebPartChrome
{
....
public override void RenderWebPart(HtmlTextWriter writer, WebPart webPart)
{
RenderWebPartHeader(writer, webPart)
RenderPartContents(writer, webPart);
RenderWebPartFooter(writer, webPart);
}
....
}
Dove i tre metodi richiamati all'interno sono due metodi privati che si occupano di renderizzare parti distinte delle mie web parts (header e footer) e il metodo standard della WebPartChrome per la renderizzazione del contenuto. Per semplifcare ulteriormente la creazione del mio look&feel ho deciso di utilizzare dei templates, ovvero un file HTML che contiene dei semplici segnaposto dove andare a sostituire le parti necessarie per il corretto funzionamento del framework delle webparts (cosa su tutte l'ID del Title, che come accennavo nell'altro post, permette il corretto funzionamento del drag&drop). Avremmo quindi un template di questo tipo :
<div id="[IDWebPart]" class="miaclass1">
<div id="[IDTitolo]" class="miaclass2">
[Titolo]</div>
<div class="miaclass3">
[Verbi]
</div>
</div>
<div>
<div class="miaclass4">
<div style="[Visibilita]">
[Contenuto]
</div>
</div>
<div class="miaclass5">
</div>
</div>
<div class="miaclass6">
</div>
Una volta realizzato il mio template sarà compito del mio CustomChrome (o di altro) andare a leggersi il file direttamente da filesystem (con eventuale verifica di data modifica) o come risorsa incorporata. Questo esempio di template viene spezzato in Header e Footer tramite il segnaposto [Contenuto], che indica dove verrà renderizzato il contenuto della web part vera e propria:
....
webPartTemplate = MyTemplateBuilder.Split(new string[] { "[Contenuto]" }, StringSplitOptions.RemoveEmptyEntries);
WEBPART_TEMPLATE_HEADER = webPartTemplate[0];
WEBPART_TEMPLATE_FOOTER = webPartTemplate[1];
....
A questo punto ecco i metodi che renderizzano Header e Footer:
private void RenderWebPartHeader(HtmlTextWriter writer, WebPart webPart)
{
writer.Write(WEBPART_TEMPLATE_HEADER
.Replace("[IDWebPart]", GetWebPartChromeClientID(webPart))
.Replace("[Icona]", webPart.ResolveUrl(webPart.TitleIconImageUrl))
.Replace("[IDTitolo]", GetWebPartTitleClientID(webPart))
.Replace("[Titolo]", webPart.Title)
.Replace("[Verbi]", RenderVerbs(webPart))
.Replace("[Visibilita]", (webPart.ChromeState == PartChromeState.Minimized)?"display:none;":"")
);
}
private void RenderWebPartFooter(HtmlTextWriter writer, WebPart webPart)
{
writer.Write(WEBPART_TEMPLATE_FOOTER);
}
Spero che questo piccolo post possa essere utile per la realizzazione di un Chrome completamente custom, operazione che a mio parere risultà un pò più macchinosa di quanto mi aspettassi, soprattutto data la fatica nella ricerca di materiale e di esempi funzionanti.
PS: ovviamente questo è un esempio scritto di getto e con un pò di taglia/incolla dal progetto che ho realizzato, quindi prendetelo giusto come piccola traccia 