venerdì 3 luglio 2009
Implementa l’interfaccia IList, usa un array che dinamicamente aumenta la sua dimensione se richiesto.
Implementazioni:
IList
Osservazioni:
Non è garantito che gli elementi nell’ArrayList siano ordinati.
La capacità dell’ArrayList è in numero degli elementi che può tenere in memoria.
Se il numero di elementi aumenta, anche la dimensione dell’ArrayList aumenterà.
Se il numero degli elementi diminuisce, per ridimensionare l’ArrayList bisognerà chiamare il metodo TrimToSize o settando
la proprietà Capacity.
Possiamo accedere agli elementi dell’ArrayList tramite un’indice. L’indice parte da 0.
L’ArrayList accetta elementi null e due elementi possono essere uguali.
Thread Safety:
I members public static sono thread safe.
Per garantire le operazioni multi-thread, bisogna istanziare un array tramite il metodo ArrayList.Synchronized
Code Snippet
- // Creates and initializes a new ArrayList.
- ArrayList myAL = new ArrayList();
- myAL.Add("The");
- myAL.Add("quick");
- myAL.Add("brown");
- myAL.Add("fox");
- // Creates a synchronized wrapper around the ArrayList.
- ArrayList mySyncdAL = ArrayList.Synchronized(myAL);
- // Displays the sychronization status of both ArrayLists.
- Console.WriteLine("myAL is {0}.", myAL.IsSynchronized ? "synchronized" : "not synchronized");
- Console.WriteLine("mySyncdAL is {0}.", mySyncdAL.IsSynchronized ? "synchronized" : "not synchronized");
Durante l’enumerazione degli oggetti nella collection potremmo comunque incappare in un’eccezzione se altri thread modificano la collezione anche se questa è sincronizzata.
Per garantire anche l’accesso durante l’enumerazione bisogna lockare la collection durante l’operazione o catchare l’eccezione per notificare il cambio anche agli altri threads.
Questo è un post introduttivo per i post seguenti questo argomento.
DataContract - Serializzazione
L’attributo DataContract è uno dei primi con cui si ha a che fare nel momento in cui si inizierà a scrivere un servizio WCF.
All’interno di un servizio WCF i dati possono avere una certa complessità; quando, gli stessi, vengono spediti vengono rappresentati
tramite un XML Schema Definition (XSD).
DataContract è il mezzo usato da WCF per mappare i tipi .NET CLR con le loro rappresentazioni XSD.
Il decoratore [DataContract] è usato per specificare quale classe deve essere specificata nell’XSD e esposto nell’WSDL esposto dal servizio.
Il decoratore [DataMember] è usato invece per specificare quali membri della classe devono essere specificati nell’XSD.
A runtime la classe DataContractSerializer serializza l’oggetto in XML usanto le regole specificate con gli attributi [DataContract] e [DataMember].
Ecco un esempio, questa è la nostra classe:
Code Snippet
- [DataContract]
- public class CompositeType
- {
- bool boolValue = true;
- string stringValue = "Hello ";
- [DataMember]
- public bool BoolValue
- {
- get { return boolValue; }
- set { boolValue = value; }
- }
- [DataMember]
- public string StringValue
- {
- get { return stringValue; }
- set { stringValue = value; }
- }
- }
Questo l’WSDL ottenuto:
Code Snippet
- <GetDataUsingDataContractResponse xmlns="http://tempuri.org/">
- < GetDataUsingDataContractResult xmlns:a="http://schemas.datacontract.org/2004/07/WcfService1" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
- < a:BoolValue>false</a:BoolValue>
- < a:StringValue>Hello </a:StringValue>
- </ GetDataUsingDataContractResult>
- </ GetDataUsingDataContractResponse>
In definitiva, la classe DataContractAttribute == [DataContract] specifica o implementa il tipo dei dati da serializzare tramite un serializer, ad esempio tramite la classe DataContractSerializer.
Per Serializzazione solitamente si descrive il processo di conversione di un oggetto in un array di bytes; tale processo viene usato per salvare lo stato di un oggetto su un file o su un database,
copiare lo stato sul clipboard, per trasferire l’oggetto tra un’applicazione ad un’altra tramire un network e per migliorarne la mantenibilità.
Con WCF, serializzare, si intende come un oggetto .NET e mappato nell’XML Infosets.
WCF supporta 3 serializer: XmlSerializer, DataContractSerializer e NetDataContractSerializer.
Tutte e 3 hanno possiedono un algoritmo di mapping diverso, ma lo scopo è sempre lo stesso: mappare gli oggetti .NET in XML Infosets.
Encoding
Abbiamo appena finito di descrivere la Serializzazione ed adesso possiamo capire che distinzione fa WCF con l’Encoding.
Encoding è il termine usato per descrivere il processo di conversione di un messaggio in un array di bytes.
WCF supporta cinque tipi di formati di encoding:
- binary
- text
- Message Transmission Optimization Mechanism (MTOM)
- JavaScript Objeect Notation
- Plain-Old-XML (POX)
Quale di questi formati usare, dipende dal tipo di applicazione che stiamo sviluppando.
Ad esempio vorremmo usare il BinaryMessageEncoder per ottimizzare le performance tra le applicazioni, oppure usare TextMessageEncoder o MtomMessageEncoder per mantenere
l’interoperabilità basata sui vecchi servizi WS-* Web Services, o usare JsonMessageEncoder per AJAX
Se provaste a usare encodings diversi per scrivere lo stesso XML Infosets, otterrete N differenti byte streams, comunque rappresenterebbero gli stessi dati.
L’encoding non è considerato parte del contratto del servizio, ma piuttosto una configurazione dell’endpoint.
Conclusione
La separazione tra Serializzazione e Encoding rende possibile la creazione di applicazioni molto flessibili.
Questo è un cavallo di battaglia di WCF, perchè gli da la possibilità di configurarsi con qualsiasi scenario.
Se abbiamo bisogno di performance allora possiamo usare un encoder se invece necessitiamo di interoperabilità allora sceglieremo un formato testuale.
Gli amici sono arrivati.
Arance, cannoli, arancine, mozzarelle in carrozza, caponatina, pani ca mivusa, cazzilli, mussu, pani e panelle, cassata, cannolo africano, iris con nutella e con ricotta,
pasta al forno, pasta tinnirumi e zucchina, parmigiana, gelsi, fichi, fichi d’india, limoni e stigghiola.
E’ realmente tutto pronto, forse mancano ancora un paio di sedie e le tovaglie di lino.
Ma le otri son piene del vino buono (Nero d’Avola, ovvio).
Adesso tocca a noi, bavaglini al collo e via di coltello e forchetta.
Buon appetito!!!
http://www.orangedotnet.org/
giovedì 2 luglio 2009
Rappresenta una lista di oggetti accessibile tramite un indice.
Implementazioni:
ICollection<T>
IEnumerable<T>
IEnumerable
Osservazioni:
Implementa l’interfaccia generica ICollection<T>.
Thread Safety:
Definisce i metodi per manipola le collezioni generiche.
Implementazioni:
IEnumerable<T>
IEnumerable
Osservazioni:
La versione non generica ICollection definisce dimensioni, enumeratore e i metodi di sincronizzazione.
Le interfacce quali IDictionary<TKey, TValue> e IList<T> sono interfacce specializzate che implementano ICollection<T> e poi le rispettive classi
ne implementano la logica.
Mentre le classi come Queue<T> e Stack<T> implementano direttamente la ICollection<T>.
Thread Safety:
mercoledì 1 luglio 2009
Espone l’enumeratore che supporta un semplice iteratore su una collezione del tipo specificato.
Implementazioni:
Osservazioni:
Il metodo che verrà chiesto di implementare è GetEnumerator il quale ritornerà l’enumeratore implementato.
Thread Safety:
Supporta un semplicissimo iteratore della collezione generica.
E’ l’interfaccia base per tutti gli enumeratori generici.
Implementazioni:
IEnumerator
IDisposable
Osservazioni:
Implementare questa interfaccia richiede l’implementazione della IEnumerator.
Ciò significa implementare i metodi MoveNext e Reset che non dipendono dal tipo dell’oggetto.
La proprietà Current è presente in entrambe le interfacce, generica e non.
Thread Safety:
Di default le collection implementate nel namespace System.Collections.Generic non sono sincronizzate.
venerdì 26 giugno 2009
martedì 23 giugno 2009
Tramite un consiglio di un amico, a causa della mia attuale mancaza di ispirazione, vi domando:
chi conosce tutte queste classi e quando è corretto usare una piuttosto che un’altra?
sabato 20 giugno 2009
Continuiamo con lo smell: Duplicated Code
Problema:
Abbiamo 2 o più metodi che eseguono lo stesso codice anche se con una sequenza logica diversa.
Un esempio di logica errata:
Code Snippet
- class Employee
- {
- public int EmpID { get; set; }
- public string EmpName { get; set; }
- public string Salary { get; set; }
- public Employee(int empID, string empName, string sal)
- {
- this.EmpID = empID;
- this.EmpName = empName;
- this.Salary = sal;
- }
- public string Display()
- {
- string s;
- s = "$" + Salary;
- //Display all Employees Details.
- s += "Employee ID: " + EmpID;
- s += "Employee Name: " + EmpName;
- s += "Employee Salary: " + Salary;
- s += "-------------------";
- return s;
- }
- }
- class Department
- {
- public int DeptID { get; set; }
- public string DeptName { get; set; }
- public string Location { get; set; }
- public Department(int deptID, string deptName, string loc)
- {
- this.DeptID = deptID;
- this.DeptName = deptName;
- this.Location = loc;
- }
- public string Display()
- {
- if (Location == "BLORE")
- {
- Location = "BANGALORE";
- }
- else if (Location == "HYD")
- {
- Location = "HYDERABAD";
- }
- else
- {
- Location = "DELHI";
- }
- //Display all Departments Details.
-
- string s = "Department ID: " + DeptID;
- s += "Department Name: " + DeptName;
- s += "Department Location: " + Location;
- s += "-------------------";
- return s;
- }
- \
Motivazione:
Il polimorfismo viene in aiuto per eliminare il codice duplicato. Quando abbiamo due subclasses con lo stesso metodo portiamo tutto nella classe base e abbiamo risolto.
Ma quando i due metodo non sono esattamente gli stessi, cosa possiamo fare?
Soluzione:
Code Snippet
- abstract class AbstractDAO
- {
- public abstract void LoadDetails();
- public abstract void FormatAndDisplayDetails();
- public virtual void StartUp()
- {
- Console.WriteLine("Start of Processing");
- Console.WriteLine("-------------------");
- }
- public virtual void Dispose()
- {
- Console.WriteLine("End of Processing");
- }
- public void Display()
- {
- StartUp();
- LoadDetails();
- FormatAndDisplayDetails();
- Dispose();
- }
- }
- class Employees : AbstractDAO
- {
- private List<Employee> empList = new List<Employee>();
- public override void LoadDetails()
- {
- //Get Data From Database.
- empList.Add(new Employee(10, "TEST", "2000"));
- empList.Add(new Employee(20, "TEST1", "3000"));
- empList.Add(new Employee(30, "TEST2", "4000"));
- }
- public override void FormatAndDisplayDetails()
- {
- //Add $ to Salary
- foreach (Employee emp in empList)
- {
- emp.Salary = "$" + emp.Salary;
- //Display all Employees Details.
- Console.WriteLine("Employee ID: " + emp.EmpID);
- Console.WriteLine("Employee Name: " + emp.EmpName);
- Console.WriteLine("Employee Salary: " + emp.Salary);
- Console.WriteLine("-------------------");
- }
- }
- }
- class Departments : AbstractDAO
- {
- private List<Department> deptList = new List<Department>();
- public override void LoadDetails()
- {
- //Get Data From Database.
- deptList.Add(new Department(1000, "HRA", "BLORE"));
- deptList.Add(new Department(2000, "FIN", "HYD"));
- deptList.Add(new Department(3000, "MARKETING", "DEL"));
- }
- public override void FormatAndDisplayDetails()
- {
- //Expand Location.
- foreach (Department dept in deptList)
- {
- if (dept.Location == "BLORE")
- {
- dept.Location = "BANGALORE";
- }
- else if (dept.Location == "HYD")
- {
- dept.Location = "HYDERABAD";
- }
- else
- {
- dept.Location = "DELHI";
- }
- //Display all Departments Details.
- Console.WriteLine("Department ID: " + dept.DeptID);
- Console.WriteLine("Department Name: " + dept.DeptName);
- Console.WriteLine("Department Location: " + dept.Location);
- Console.WriteLine("-------------------");
- }
- }
- \
Benefici e non
+ Rimuove il codice duplicato.
+ Nasconde come si comporta l’algoritmo a seconda dell’oggetto.
+ Permette alle sottoclassi di customizzare l’algoritmo.
- Complica il design. |
E non prendete come scusa: “il mio sistema ormai è troppo evoluto per poterne apportare queste migliorie. E’ troppo tardi.”
Se fosse realmente così non esisterebbe il Refactoring :)