Cloud as a Story - Vunvulea Radu

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> <

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 s

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ți

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

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 ref