maggio 2014 Blog Posts
Ai Community Days di quest’anno abbiamo sproloquiato di scalabilità, una delle cose su cui ho cercato di insistere è che per poter parlare di scalabilità è necessario in primis essere in grado di misurare e definire quali sono i requisiti che devono essere rispettati. Questo per un semplicissimo motivo: la scalabilità infinita è un mito, fine, è il requisito che ci deve far scegliere come scalare e non la semplice necessità di scalare. Facciamo un esempio banale e un po’ astratto per capire: Abbiamo un bel sito web di e-commerce, piccolo piccolo che fa...
Abbiamo già parlato del lavoro legato alla performance di Radical, i punti toccati non sono stati poi molti, il voro nocciolo della questione giro intorno ad un signore che si chiama “Ensure” e che vi permette di scrivere qualcosa del tipo: class MyClass
{
public void Foo( String arg )
{
Ensure.That( arg ).Named( () => arg ).IsNotNullNorEmpty();
}
}
A runtime quello che succede è che se “arg” è null o empty vi beccate una simpatica eccezione con tutti i dettagli del caso, compreso:
...
Aurelio è uno dei tanti fruitori di Radical (che vi ricordo ha cambiato casa) e mi ha segnalato un fastidioso problema di performance nel momento in cui viene messa in binding una list di entità, basate sulla classe base “AbstractViewModel” di Radical, la cui numerosità sia corposa: Nell’esempio, che Aurelio ha prodotto per riprodurre il problema, a sinistra vengono create 2.000 istanze di un banalissimo ViewModel che implementa direttamente INotifyPropertyChanged, mentre a destra viene fatta la stessa cosa con un ViewModel che eredita da “AbstractViewModel”. Come si nota i tempi sono abissalmente superiori e anche inaccettabili...