IComparer generic - propietatea Default

De obicei cand dorim sa putem compara doua obiecte de acelasi tip folosim IComparar. Aceasta ne pune la dispozitie metoda

int Compare(T x, T y);

Valorea returnata de aceasta metoda poate sa fie:

• >0 - daca x este mai mare ca y;
• =0 - daca x este egal cu y;
• <0 - daca x este mai mic ca y;

In cazul in care una( sau amandoua) din valori, metoda poate sa returneze:

• >0 - daca y este null;
• =0 - daca x so y sunt null;
• <0 - daca x este mai mic ca y;

Dar pentru a putea face aceasta comparatie una din valori trebuie sa fie diferita de null, atlfel o sa avem parte de NullReferenceException. Pentru a putea rezolva aceasta problema putem sa avem ceva de genul:

var valoare = x == null ? ( y == null ? 0 : -1 ) : x.CompareTo(y);

Este necesar sa verificam daca una din valor este null. Valoarea lui y nu trebe sa o verificam obligatoriu, dar cea a lui x trebuie sa o verificam mereu.
Pentru a rezolva acest neajuns, avem la dispozitie propietatea Default pe IComparable. Aceasta va crea automat comparatorul default pentru tipul de data dat. De exemplu daca lucram cu un obiect de tip nullable, putem sa evitam sa facem verificarea descrisa mai sus folosind aceasta propietate:

int? x,y;
// ...
var valoare = Comparar<int?>.Default.Compare(x,y);

Acesta va crea instanta in regim de Singleton, o instanta a clasei Comparer. Tipul de data T pe care il folosim trebuie sa implementeze interfata IComparable.
Aceasta propietate ne poate scapa de grijile de a verifica fiecare element daca este null inainte de a face compararea.

Read More

AutoMapper - object to object mapper

Acest mic framework ne ajuta cand trebuie sa mapam doua entita cu aceleasi propietati. In mod traditional pentru a face acest lucru trebuie sa scriem ceva de genul:

CarDb carDb = LoadFromDb(id);
// ...
Car car = new Car()
     {
          Type = carDb.Type,
          Number = carDb.Number,
          Owner = varDb.Owner,
          RegFrom = carDb.RegFrom                            
     };

Acest caz apare mai ales cand avem o aplicatie pe mai multe nivele, iar modelul care persista in baza de baza de date si modelul care ajunge la client sunt diferite.
Ce poate sa faca AutoMapper, este sa faca automat copierea valorilor proprietarilor, fara sa mai scrim noi cod. In cazul in care propietatea primeste o alta valorea sau are un nume diferit, putem sa scriem o expresie lambda care sa faca conversia.
Mai jos o sa gasiti cateva exenple:
1. Mapare intre doua entitati Car si CarDb

// Creare mapare.
Mapper.CreateMap<CarDb,Car>() ;
// Conversia propriu-zisa.
Car car = Mapper.Map<CarDb,Car>(carDb) ;

In loc sa avem o lista de propietati la care sa facem atribuiire, a fost nevoie sa apelam doar metoda CreateMap.
2. Maparea a doua propietati de tipuri diferite.
Sa presupunem ca Car contine o propietate IsHit de tip bool, iar CarDb contine aceiasi propietate, dar este de tipul int.
Pentru acest lucru este nevoie sa cream un nou ValueResolver care sa stie sa convertească din int in bool. ValueResolver este un tip de data definit de AutoMapper, folosit pentru a face conversii intre date.

public class HitIntToBoolResolver : ValueResolver<int,bool>
{
     protected ovveride bool ResolveCore(int val)
     {
          return val==1;
     }
}

Iar pentru a face maparea trebuie pe CreateMap sa adaugăm resolver-ul custom:

Mapper
     .CreateMap<CarDb,Car>()
     .ForMember(
          car => car.IsHit,
          x => x.ResolveUsing<HitIntToBoolResolver>().FromMember( m => m.IsHit));

In acest moment, pentru propietatea IsHit, se va face o conversie automata din int in bool.
3. Cum sa atribuim o valoare custom la o propietate.
Sa presunem ca entitatea Car are o propietate FullNumber de tip string formata din RegDate+Number. Pentru a putea seta aceasta valoare in AutoMapper este nevoie sa scriem urmatorul cod:

Mapper
     .CreateMap<CarDb,Car>()
     .ForMember(
          car => car.FullNumber,
          x => x.MapFrom( e => e.RegDate.ToString() + e.Number ));

In acest fel putem genera valori custom orice propietati.
4. In cazul in care entitatea are propietati care la randul lor trebuie mapate, ajunge sa definim maparea tuturor tipurilor de date implicate, in ncazul nostru este nevoie sa definim o mapare in plus pentru tipul de data Builder( presupunem ca entitatea Car are o propietare cu numele BuildBy de tip Buildder.

Mapper.CreateMap<BuilderDb,Builder>

AutoMapper va detecta automat ca aceasta propietate este deja mapata si va folostii maparea definita deja.

Mapper.CreateMap<BuilderDb,Builder>();
Mapper .CreateMap<CarDb,Car>();
Car car = Mapper.Map<CarDb,Car>(carDb) ;

Din punct de vedere a vitezei, nu va asteptati sa fie la fel de rapid. In spate AutoMapper se bazeaza pe Reflection. Fata de o mapare manuala este undeva de 6-7 ori mai lent. In cazul in care nu aveti nevoie de mii de conversii pe secunta, cred ca AutoMapper este o solutie foarte buna. Obtinem un cod mai usor de intretinut si mult mai clar.
Link:

https://github.com/jbogard/AutoMapper

http://automapper.codeplex.com/

Read More

HTML: Cum sa facem disable un element din drop down.

Uneori avem nevoie pe UI sa facem un element dintr-un drop-down disable. Utilizatorul sa il poata vedea, dar sa nu il poata selecta. Aceasta varianta este foarte utila cand un update la o aplicatie deja existenta, unele optiuni dispar. Pana cand toti utilizatori o sa isi faca update la configuratie( backward compatibility).
Pe fiecare optine dintr-un select avem atributul disable ce care il putem seta. Pana aici totul pare in regula:

<select name="telefon">     <option value="1">Nokia</option>     <option value="2" disabled="disabled">LG</option>     <option value="3">Samsung</option></select>

Optiunea de LG nu o sa poata fi selectata, dar utilizatorul o poate vizualiza, iar din codul de java script se poate selecta aceasta valoare.
Ar aparea ceva de genul acesta:
Nokia LG Samsung
Singura problema este cu IE. Acesta nu suporta acest atribut. Pentru a rezolva acest neajuns putem sa folosim urmatorul cod javascript:

<script>
function AddOptionsDisabledSupport(){
    var allSelectItems = document.getElementsByTagName('select');
        for(var i=0; i < allSelectItems.length; i++){
            allSelectItems[i].onchange= function(){
            if(this.options[this.selectedIndex].disabled){
                if(this.options.length<=1){
                    this.selectedIndex = -1;
                }else
                if(this.selectedIndex < this.options.length - 1){
                    this.selectedIndex++;
                }else{
                    this.selectedIndex--;
                }
            }
        }
       
        //Change the color to gray.
        for(var j=0; j < allSelectItems[i].options.length; j++){
            if(allSelectItems[i].options[j].disabled){
                allSelectItems[i].options[j].style.color = '#CCC';
            }
        }
    }
}

//Run each time when page is loaded.
window.attachEvent("onload", AddOptionsDisabledSupport)
</script>

Iar de acuma acest atribut o sa poata fi folosit si pe IE.

Read More

Propietati de tip array in tabelele din Windows Azure (part 2)

Partea 1 http://vunvulearadu.blogspot.com/2011/02/propietati-de-tip-vector-in-tabele-din.html
Continuare:
In ultimul meu post am descris trei variante prin care se poate persista o entitate care contine o propietate de tip array( lista) intr-un tabel. Ultima varianta, care la prima vedere pare cea mai buna era folosind DataServiceContext.
Aceasta solutie este viabila, atata timp cat nu trebe sa facem un query direct pe tabel. In acest moment tabelel din Windows Azure nu suporta pe query expresii de genu:

• Contains
• Count
• Select

Din aceasta cauza, daca avem o propietate de tip lista nu o sa putem avea un query de genul:

(item => item.ListaElemente.Contains(id)

Din aceasta cauza, pentru a putea face un astfel de query ar fi nevoie sa incarcam toate elementele din tabel si sa le procesam din cod, cea ce nu tocmai optim.
Dar nici prima varianta nu se poate folosii din pacate( lista sa fie stocata ca si un string cu un caracter despartitor), din cauza ca urmatorul query nu este suportat:

(item => item.ListaElementeSz.Contains(id.ToString())

Nu putem sa avem un query care sa foloseasca metoda Contains() pe string.

Singura varianta ramasa este a 2-a, folosirea unei tabele intermediare .

Read More

Propietati de tip array in tabelele din Windows Azure( part 1)

Am inceput sa folosesc din plin tabelele din Windows Azure. Orice fel de date se pot salva acolo, atata timp cat sunt serializabile.
Cu ajutorul lor am facut maparea unor entitati fara probleme. Am ajuns in momentul in care intre doua entitati A si B aveam o relatie n la m, iar intre alte doua entitati 1 la n. Fara nici o problema am scris:

public List<Guid> ItemIds { get; set; }

Am continuat sa scriu codul in continuare fara nici o problema, iar intr-un final am ajuns la unit-teste unde am avut o surpriza nu tocmai placuta. Cea ce am ignorat de la bun inceput a fost faptul ca tabele din Windows Azure nu sunt O/R, ele nu stiu sa stocheze in mod default o lista.
Greseala mea, fapta fiind deja comisa a trebuit sa caut solutii la aceasta problema. Am gasit urmatoarele solutii:

• o propietate de tip string care sa stocheze id-urile despartite printr-un caracter special. Solutia destul de viabila, daca tinem cont de faptul ca obiectele care se stocheaza pe tabele nu ajung sa fie folosite pe partea logica si/sau client side;

• o tabela intermediara care sa stocheze relatiile intre cele doua obiecte. Pare o solutie bunicica, dar ma sperie putin ideea de a crea aceste tabele intermediare;

• ultima solutie gasita care m-a incantat cel mai mult este prin folosirea lui DataServiceContext. Acesta ne permite sa controlam momentul in care o entitate se salveaza sau se incarca dintr-un tabel si sa modificam continutul care se salveaza.

O sa detaliez mai jos aceasta varianta. Windows Azure salveaza toate aceste obiecte din tabele in format Atom Feed. Ce inseamna asta pentru noi? Pai, noi putem controla cea ce se salveaza si sa modificam continutul care ajunge sa fie salvat pe "tabele". Asa cum putem controla serializarea si deserializarea, cu ajutorul la DataServiceContext putem controla valoarea care se persista in tabele. Avem la dispozitie doua "metode":

• ReadingEntity: pentru citirea din tabel;
• WritingEntity: pentru scrierea in tabel;

Un exemplu de implementare puteti sa gasiti aici:
http://convective.wordpress.com/2009/12/30/entities-in-azure-tables/
In momentul acesta am de ales intre ultimele doua variante. Cred ca o sa aleg ultima varianta din cauza si altor neajunsuri pe care le are in momentul de fata Windows Azure la capitolul tabele( modul in care se genereaza un query).
Partea a 2-a: http://vunvulearadu.blogspot.com/2011/02/propietati-de-tip-array-in-tabelele-din.html

Read More

Cum sa "NU" rulezi mai mult de un serviciu windows din acelasi process.

Daca vrem sa pornim mai mult de un serviciu in acelasi proces avem nevoie sa apelam urmatorul cod:

services = new ServiceBase[]
                                              {
                                                  new DeleteService(),
                                                  new CopyService(),
                                                  new LoadService(),
                                              };
ServiceBase.Run(services );

Dupa ce o sa executam acest cod o sa avem surpiza sa observam ca doar primul serviciu din lista a ponit. In prima faza ne gandim ca avem acelasi nume, asa ca verificam la cele trei servicii numele. Totul pare in ordine.
Urmatorul pas este sa setam serviciul pe "Share" type. Pentru acest lucru trebuie facut:

sc config "NumeServiciu" type=share

Dar din pacate problema se manifesta in continuare. Doar primul serviciu din lista de servicii porneste.

Am renuntat la acesta idee si am facut cate in install pentru fiecare servciu in parte.

Read More

System.Web.Helpers.Json.Decode + dynamic = generic deserialization

Azi am făcut o mare descoperire. Prin helpe-ul de web am gasit metoda Json.Decode. Se poate folosii oriunde nu doar in aplicațiile web. Este nevoie doar sa referim System.Web.Helpers.
Cu ce ne ajuta, putem face decode la orice obiect serializat prin Json, iar in combinatie cu dynamic type obtinem urmatorul cod:

var webClient = new WebClient();
var jsonResult = webClient.DownloadString("URL");
var result = Json.Decode(jsonResult);
//result.response.sets.items - depinde de cea ce returneaza Json
var listItem = new List<dynamic>(result.response.sets.items);

In listItem avem deja o lista de obiecte de orice tip deserializate. Singurul lucru in minus este ca propietatiile care se acceseaza dintr-un obiect de tip dynamic nu sunt strong type. Doar la runtime o sa stim daca proprietatea exista sau nu - din cauza la DLR( Dynamic Language Runtime).

Read More