Care este cel mai rapid mod prin care putem consuma un serviciu REST

In ultima perioada din ce în ce mai multe servicii publice în format REST au apărut pe piaţa.
O problema destul de neaşteptata apare pe partea de client:
Cum sa consumam un serviciu REST?
Din start, .NET ne oferă doua variante destul de simple pentru a putea utiliza un serviciu REST:

• WCF Client - Service Contract;
• WebRequest;

Pentru a putea consuma un serviciu folosindu ne de WCF avem nevoie sa ne declaram un contract (ServiceContract) în care sa specificam operaţiile care ne sunt puse la dispoziţie.

[ServiceContract()]
[XmlSerializerFormat()]
public interface ICarClient
{
[OperationContract]
[WebGet(
ResponseFormat = WebMessageFormat.Xml,
UriTemplate = "Car/{id}?userkey={userKey}")]
Car GetCar(string id,string userKey);
}

La acest nivel am definit prin atributul WebGet locaţia acestei resurse (UriTemplate) relativa la adresa setata în fişierul de configurare. Urmatorul pas este sa ne configuram un endpoint in fisierul de configurare de forma:

<system.servicemodel>
 <client> 
   <endpoint address="http://www.carCollection.com/" binding="webHttpBinding" behaviorconfiguration="CarRestBehavior" contract="CarEx.ICarClient" name="CarRestEndpoint">
 </endpoint>
 <behaviors>
   <endpointbehaviors>
     <behavior name="CarRestBehavior">
       <webhttp>
     </webhttp>
   </behavior>
 </endpointbehaviors>
</behaviors>

Este foarte important la acest pas sa configuram comportamentul la endpoint şi sa îl setam pe "webHttp".
Odată ce am făcut acest lucru putem sa ne cream un proxy prin intermediul la ChannelFactory, iar mai departe sa apelam serviciul dat.

ChannelFactory factoryCar = new ChannelFactory("CarRestEndpoint");
ICarClient carClientProxy = factoryCar.CreateChannel();
Car car = carClientProxy.GetCar("1","userKey");

Nu vreau sa intru în mai multe detalii pe partea de configurare. In cazul in care avem noroc ca serviciul pe care vrem sa îl consumam are definit un WSDL (Web Service Definition Language), atunci ajunge doar sa adaugăm în proiect o referința la serviciu ("Add Service Referince").
Pentru a putea consuma un serviciu REST putem sa folosim și WebRequest (care este mult mai ușor de folosit).

WebRequest request = WebRequest.Create("http://www.carCollection.com/Car/1?userKey=userKey");
WebResponse webResponse = request.GetResponse();
XmlSerializer xmlSerializer = new XmlSerializer(typeof(Car));
Car car = (Car)xmlSerializer.DeserializewebResponse.GetResponseStream());

Este destul de simplu, este nevoie sa specificam adresa și sa facem un request. Răspunsul o sa îl primim ca un stream pe care trebuie apoi sa îl deserializam. Partea de procesare stream și deserializare trebuie sa o facem manual.
Si acuma apare o noua întrebare, care m-a făcut sa scriu acest post:
Care din cele doua mecanisme credeți ca este mai rapid?
La prima strigare am spus ca WCF Client. In spate avem o colecție de librarii dezvoltate în timp. Acestea ar trebuii sa fie optimizate și sa meargă excelent, dar iată ce rezultate am obținut în urma testelor:

• WCF Client: 35s
• Web Request: 11s

La prima vedere nu am înțeles foarte bine cauza dar apoi am găsit mai multe cauze pentru acest lucru.
Un apel de tip web request este extrem de simplu, iar WCF este mult prea complicat pentru ce avem nevoie noi. Deșii oferă o multitudine de opțiuni, de foarte multe ori pentru un web request noi folosim doar 1% din cea ce ne oferă, caz în care încărcam multe librarii fără nici un rost.
Prin WCF suntem nevoiți sa trecem printr-un flow extrem de complex care implica mecanisme costisitoare din punct de vedere a timpului precum reflection.
Asta nu inseamna ca o sa ne fie ușor sa folosim Web Reques, pot sa apară cazuri când este mult mai ușor sa lucram cu ChannelFactory (WCF) si nu cu web request dar din punct de vedere a timpului, un web request o sa fie mereu mai rapid.

Read More

How to lock a method - synchronized

Nu odată mi s-a întîmplat sa am nevoie sa sincronizez una sau mai multe metode din aceiași clasa.
In funcție de situație foloseam un cod asemănător cu cel de mai jos:

class ItemsStore
{
   void AddItem(Item item)
   {
       lock(this)
       {
           ...
       }
   }
 
   void RemoveItem(Item item)
   {
       lock(this)
       {
           ...
       }
   }
 
   Item[] GetAvailableItemes()
   {
       lock(this)
       {
           ...
       }
   }
}

Sunt cazuri când lock-ul se face pe un field sau pe un obiect diferit de this dintr-o alta clasa. Unu din dezavantaje care apare în acest caz este apariția a unui nou nivel de indentare.
Am descoperit un alt mecanism prin care se poate face lock automat pe metodele dorite. Deși exista din .NET 1.1 și cea mai mare parte din voi l-ați folosit deja, am considerat ca merita amintit.
Prin intermediul atributului MethodImpl putem specifica modul în care sa se facă lock-ul pentru fiecare metoda în parte( nu mai este nevoie sa folosim lock sau SyncLock) și nu numai. Prin acest atribut putem de fapt sa specificam de fapt modul în care o metoda se implementează.
Codul scris mai sus îl putem rescrie în forma următoare:

class ItemsStore
{
   [MethodImpl(MethodImplOptions.Synchronized)]
   void AddItem(Item item) { ... }
 
   [MethodImpl(MethodImplOptions.Synchronized)]
   void RemoveItem(Item item)    { ... }
 
   [MethodImpl(MethodImplOptions.Synchronized)]
   Item[] GetAvailableItemes()    { ...  }
}

Personal cred ca în felul acesta codul devine mai ușor de înțeles si mai clar. Cea ce trebuie avut grija este ca MethodImplOptions.Synchronized face lock pe obiect și nu în toate cazurile avem nevoie de acest lucru.
Enumul MethodImplOptions ne permite sa setam următoarele stări pe care le putem combina:

• Unmanaged - Specifies that the method is implemented in unmanaged code.
• ForwardRef - Specifies that the method is declared, but its implementation is provided elsewhere.
• PreserveSig - Specifies that the method signature is exported exactly as declared.
• InternalCall - Specifies an internal call. An internal call is a call to a method that is implemented within the common language runtime itself.
• Synchronized - Specifies that the method can be executed by only one thread at a time. Static methods lock on the type, whereas instance methods lock on the instance. Only one thread can execute in any of the instance functions, and only one thread can execute in any of a class's static functions.
• NoInlining - Specifies that the method cannot be inlined.
• NoOptimization - Specifies that the method is not optimized by the just-in-time (JIT) compiler or by native code generation (see Ngen.exe) when debugging possible code generation problems.

Sursa: http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions.aspx

Enjoy it.

Read More

Fluent interface pattern

Asa cum am promis revin cu un post despre Fluent Interface.
Fara sa vrem am ajuns sa folosim acest patern aproape în fiecare zi. Când scrieți o comanda

LINQ
items
    .Where(x => x.Name == "Radu")
    .Select(x.CNP);
sau faceți un setup la un MOCK
objMock
    .Setup(x => x.GetAge())
    .Return(20);

în spate într-o oarecare măsura folosit Fluent Interface Pattern. Unii dezvoltatori ajung sa scrie un API bazat pe acest patern fără sa își dea seama, ajungând la el într-un mod natural.
Îmi este destul de greu sa dau o definiție fixa la acest pattern. Este un mod de a scrie codul a.i. cel care îl va utiliza o sa poată sa execute o anumita acțiune( flow) prin intermediul ".". Utilizatorul ar trebui sa fie constrâns de API sa facă toate setările necesare pentru a executa o acțiune.
De exemplu pentru a putea sa ne deplasam cu o mașina, trebuie:
sa introducem cheile în contact;
sa pornim motorul;
sa ne asiguram ca mașina este în viteza;
sa apăsam pedala de accelerație;
Dupa cum putem observa avem definit un flow care trebuie sa se execute într-o anumita ordine. Ca sa constrângem utilizatorul sa execute acest flow într-o anumita ordine putem sa ne folosi de fluent interface. Una sau mai multe acțiuni de pe același nivel se pot executa doar dacă s-au executat actiniile dinaintea lor.
Pentru a putea face acest lucru fiecare nod din flow poate sa returneze un obiect de un anumit tip. Astfel încât am obține:

car
    .InsertKey()
    .StartEngine(key)
    .SetGear(1)            // In aceasta locația am putea face Stop()
    .PressThrottle(0.1)

Cea ce este important de știut este faptul ca metodele nu trebuie sa returneze același obiect. Ele pot sa returneze și obiecte de tip diferit.
Ca sa generam un număr foarte mare de obiecte, putem ca obiectul Car sa implementeze toate interfețele implicate pentru fiecare nod din flow, iar fiecare acțiune sa returneze interfața( de fapt se returnează this, doar 'convertit' la interfața respectiva - în acest caz utilizatorul poate sa execute doar un număr limitat de comenzi, în cazul în care nu face conversia).
Un exemplu de API în format fluent interface este următorul:

public interface ICmdCar
{
    ICmdCar Go(int dist);
    ICmdCar Left();
    ICmdCar Right();
    ICar Stop(); 
}
public interface IInitCar
{
    IInitCar SetPower(int value);
    IInitCar SetGearBox(int type);
}
public interface ICar
{
    ICmdCar Start();
    IInitCar Setup();
}

Putem sa observam ca s-a strecurat o mica greșeala. Comanda Start() se poate apela fără sa se facă setup-ul la mașina.
O soluție la aceasta problema este ca o instanta a unui obiect de tip IInitCar sa fie transmisa prin constructorul sau sa avem un factory. O soluție puțin mai complicata este sa mutam acțiune de Start() in IInitCar.
Acest pattern ne ajuta sa facem un API mai:

• accesibil;
• lizibil;
• ușor de folosit;
• restrictiv;

Avantaje:

• apare un layer de separare;
• decuplarea și reutilizarea componentelor;
• definirea unui flow este mult mai usor;
• eliminarea excepțiilor pentru validare și a gărzilor;
• intellisense;

Vreau sa explic penultimul avantaj. In general dacă pentru executarea unui acțiuni avem nevoie ca mediul sa fie setat într-un anumit fel, este necesar sa verificam starea mediului înainte sa executam acțiunea. Daca folosim fluent interface nu mai este nevoie sa facem acest lucru deoarece pentru a ajunge în acel punct userul a fost constrâns sa treacă prin niște etape( care l-au obligat sa facă setările necesare). O alta soluție care se folosește pentru a rezolva aceasta problema este validarea prin AOP, dar nu o sa intru în detaliu).
Dezavantaje:

• metodele luate separat nu au sens;
• pot sa apară un număr mai mare de clase( cea ce nu este neapărat un lucru rău);
• designul API-ului este greu de realizat;

Din punctul meu de vedere, un API în acest format nu o poată sa fie scris din momentul în care a început proiectul, deoarece de foarte multe ori flow-urile nu sunt încă definite. Niciodată nu o sa putem spune ca API pe care noi îl oferim în format fluent interface este perfect și nu mai necesita îmbunătățiri deoarece mereu o sa putem schimba ceva ca sa îl facem mai ușor de folosit și mai natural.
Acesta nu are nici o valoare singur. Ca orice alt pattern el trebuie sa fie îmbinat și cu alte pattern-uri.

Read More

Fields vs properties

De unde a pornit totul:
De la o discutie in care se spunea ca la inceput este mai bine sa folosim field-uri si nu proprietatiile, iar in cazul in care ajungem sa avem nevoie de ele, le putem înlocuii in orice moment cu propietati.

Aici apare o problema. Din punct de vedere a framework-ului field-urile si proprietatiile sunt total diferite (sunt binar incompatibile). Din aceasta cauza o sa fim nevoiti sa recompilam toate assembly-urile care folosesc obiectul nostru.
In cazul in care folosim reflection la accesarea field-urilor trebuie modificat, deoarece modul in care proprietatiilese acceseaza este diferit.
Singurul avantaj care apare la field-uri este performanta, care poate sa fie îmbunătățita foarte mult. Totodata field-urile pot sa fie folosite ca si parametri ref sau out.
Cand se folosesc propietati se poate controla modul in care valoarea se seteaza (validare) sau se obtine (get,set). In cazul in care modifiarea unei proprietati produce modificarea altor valori, acest lucru poate sa fie foarte usor de facut cu o proprietate.
Problema s-ar pune intre proprietăți automate si field-uri publice. Din punct de vedere a implementarii, este mult mai usor sa schimbam implementarea la o proprietate daca vrem sa facem ceva mai special, fara sa fim nevoiti sa recompilam toata solutia. De exemplu sa avem private setter.
Cea ce nu putem face cu proprietati, este sa le setam o valurea de default in mod automat. Acest lucru trebuie facut in constructor sau intr-o metoda de initializare.

• Ca si concluzie o sa enumar avantajele pe care le avem daca folosim proprietati publice si nu field-uri publice:
• lazy loading;
• propietatiile pot sa arunce erori;
• daca lucram cu data binding trebuie sa folosim propietati;
• se poate adauga validare cand o valoare se seteaza;
• fine-grained control (logging intr-un fisier de exemplu, validare);
• pot sa fie virtual si se poate face overwritten;
• pot sa apara in interfata;

Ce parere aveti? Exista un motiv pentru care am putea sa avem field-uri publice?

Read More

Dispose and finalize

Am avut o discutie zilele astea cu un coleg despre Dispose() si Finalize(), despre modul in care se apeleaza cele doua. O sa prezint pe scurt cele doua metode.
Pentru a implementa metoda Dispose() este nevoie sa implementa interfata IDispose(). Aceasta metoda nu primeste nici un parametru. Se apeleaza de catre dezvoltator cand se doreste sa se elibere resurse folosite de aceasta entitate.
Resursele unmanaged sunt eliberate prin intermediul acestei metode si reprezinta reponsabilitatea utilizatorului.
Pana aici totul este destul de clar.

public class ProcessData: IDispose
{
    private Stream _fileStream;
    //....
    public void Dispose()
    {
         _fileStream.Dispose();
    }
}

Inainte sa explic ce face metoda Finalize si de cine este apelata vreau sa explic cum functioneaza pe scurt GC:

• Cauta toate resursele (obiectele) managed care sunt referite in codul managed;
• Incearca sa faca Finalize pe obiectele care nu mai sunt referite in cod;
• Elibereaza obiectele care nu mai sunt referentiate;
• Elibereaza spatiul din memorie ocupat de acestea;

Metoda Finalize() este apelata de catre GAG si reprezinta procesul in care GC elibereaza resulsele inainte sa distruga instanta unui obiect. Acesta ar trebuii sa elibereze doar resulsele externe care sunt referentiate. Aceasta metoda este apelata in mod automat, nu se poate controla (in general) momentul in care se apeleaza.
Trebuie avut grija cand se implementeaza aceasta metoda deoarece ordinea in care care se apeleaza Finalize() nu poate sa fie controlata.
Cea ce este bine de stiut, este ca in momentul in care se implementeaza Finalize() si Dispose() se recomanda ca Finalize() sa execute si codul care apare in Dispose(). GC nu o sa apeleze niciodata Dispose().
Totodata metoda Finalize() trebuie sa apeleze obligatoriu base.Finalize(), recomanda intr-un bloc finnaly:

protected override void Finalize()
{
      try
      {
          //Code Cleanup
      }
      finally
      {
          base.Finalize();
      }
}

Urmatoarele reguli trebuie respectate cand se implementeaza Finalize():

• Trebuie sa fie mereu protected;
• Trebuie sa apeleze base.Finalize();
• Trebuie sa elibere resursele unmanaged;
• .NET nu garanteaza ca Finalize() se va executa pentru fiecare instanta separat intr-un anumit moment;
• Nu faceti new aceasta metoda;
• Nu aruncati exceptii din Finalize();
• Nu il definiti in date de tip value type;
• Nu implementati Finalize() cu body gol, deoarece se consuma resurse fara rost;

Acest mecanism trebuie sa fie considerat un mecanism de fallback. Pentru eliberea resurselor se recomanda sa se folosesca Dispose(), iar Finalize() sa apeleze la randul lui codul care se executa in Dispose().
Dar Dispose() nu face release la obiect. In cazul in care dispose-ul elibereaza resursele, atunci nu mai este nevoie sa executam si Finalize(). Pentru a spune la GC sa nu mai ruleze Finalize() trebuie sa scriem urmatoarea linie de cod in metoda Dispose():

GC.SuppressFinalize(this).

Mai jos gasiti un exemplu cum sa se apeleze Dispose():

class StoreManager: IDisposable
  {
    private bool isDisposed = false;

    ~StoreManager: ()
    {
      Dispose(false);
    }

    protected void Dispose(bool disposing)
    {
      if (disposing)
      {
        // Dispose la resurse
      }

      isDisposed = true;
    }

    public void Dispose()
    {
      Dispose(true);
      GC.SuppressFinalize(this);
    }
  }

Parca Finalize() si Dispose() sunt mai clare acuma.

Read More