[C#] Scrivere classi per la memorizzazione dei dati caricati da database

[luca_gt]

Ciao a tutti,

sono un programmatore (vecchia scuola) e mi sto addentrando nella programmazione ad oggetti. Sto leggendo molti testi e forum compreso il vostro che ritengo tra i più validi. Non so se è cosa comune ma quando si leggono gli esempi dei libri sembra tutto chiaro, mentre andando a realizzare delle applicazioni reali la poca chiarezza iniziale diventa "poche idee ben sparse e confuse". Mi piacerebbe avere i vostri suggerimenti su come implementare correttamente l'esempio riportato:

public class Company
 {
 public Company()
 {
 Name = null;
 Email = null;
 }
 
public long Id { get; set; }
 public string Name { get; set; }
 public string Email { get; set; }
 }
 
public class Unit
 {
 public long Id { get; set; }
 public long CompanyId { get; set; }
 public string Address { get; set; }
 }

In un altro file .cs:

public class db
 {
 
public static List<Unit> GetUnitByCompanyID(long id)
 {
 SqlCommand myCommand = new SqlCommand("SELECT * FROM Unit WHERE companyid = @CID");
 SqlParameter myParam = new SqlParameter("@CID", SqlDbType.BigInt);
 myParam.Value = id;
 myCommand.Parameters.Add(myParam);
 List<Unit> myListUnit = new List<Unit>();
 
using (DataTable dt = SQLProvider.GetDataTable(myCommand))
 {
 foreach(DataRow dr in dt.Rows)
 {
 Unit myUnit=new Unit();
 myUnit.Id = (Int64)dr["id"];
 myUnit.CompanyId = (Int64)dr["companyid"];
 myUnit.Address = dr["address"].ToString();

 myListUnit.Add(myUnit);
 }
 }
 return myListUnit;
 }
 return null;
 }
 
public static Unit GetUnitByID(long id)
 {
 // indentica a GetUnitByCompanyID cambia solo la query
 }

public static Unit GetUnitbyAddress(string address)
{
// indentica a GetUnitByCompanyID cambia solo la query
}

Quale sarebbe il modo corretto di implementare questo comune problema? In particolare come posso evitare di riscrivere sempre lo stesso codice visto che cambia solo la query? Devo utilizzare costruttori, overloading e interfacce?
Ringrazio chi avrà la pazienza di rispondermi.

Ciao, Luca.

[Il Totem]

Esistono framework scritti apposta per fare tutto questo in automatico. I più validi sono LINQ to Entities e LINQ to SQL. In particolare, l'Entity Framework è il più recente e con un modello ad oggetti migliore.
http://msdn.microsoft.com/it-it/library/bb386964.aspx

[luca_gt]

Ciao Il Totem e grazie per la risposta.

Il mio problema non è quello di trovare la tecnologia più adatta allo scopo (Linq to Sql, Linq to Entities, NHibernate, Entity Framework, etc) peraltro già studiati e provati, bensì capire la metodologia di approcio al problema con gli oggetti.

Ragionando a "vecchio modo" farei una funzione parametrica ma non credo sia la metodologia corretta.

Grazie di nuovo.

Luca

[alka]

Originariamente inviato da luca_gt
Il mio problema non è quello di trovare la tecnologia più adatta allo scopo (Linq to Sql, Linq to Entities, NHibernate, Entity Framework, etc) peraltro già studiati e provati, bensì capire la metodologia di approcio al problema con gli oggetti.

Il problema non è ancora chiaro, tant'è che l'hai espresso con del codice che chiedi di correggere o migliorare senza dire però qual è il problema che hai su quel codice nello specifico, e che noi non possiamo indovinare.

Originariamente inviato da luca_gt
Ragionando a "vecchio modo" farei una funzione parametrica ma non credo sia la metodologia corretta.

Una funzione parametrica per fare cosa, di preciso?

[luca_gt]

Ciao Marco e grazie per il supporto.

Per funzione parametrica intendo una funzione alla quale passo come parametro la stringa della query Sql e mi ritorna una lista di oggetti Unit ( List<Unit> ) in base alla chiave di ricerca impostata.

Questo sistema sicuramente funziona ma ritengo che non sia in linea con la programmazione ad oggetti. Mi pare di capire che sia necessario istanziare una interfaccia per la collection Unit, ma sinceramente non saprei come sia corretto implementare il tutto.

Grazie e ciao.

Luca

[alka]

Originariamente inviato da luca_gt
Per funzione parametrica intendo una funzione alla quale passo come parametro la stringa della query Sql e mi ritorna una lista di oggetti Unit ( List<Unit> ) in base alla chiave di ricerca impostata. Questo sistema sicuramente funziona ma ritengo che non sia in linea con la programmazione ad oggetti.

Fermo restando che, a mio avviso, la programmazione ad oggetti non impone che tutto debba essere strutturato secondo una gerarchia complessa o un sistema intricato di incastri, ma semplicemente pone le basi per poter creare funzionalità che lavorino vicino ai dati, con la possibilità di proteggerli e di condividere ed estendere la logica modellando il sistema secondo questi principi.

Mi spiego: solo perché si programma ad oggetti e si hanno le varie proprietà di incapsulazione, ereditarietà e polimorfismo, non significa che - per accedere a un database - non sia sufficiente e accettabile creare una semplice classe statica con i metodi che eseguono query e ritornano oggetti.

In breve, non è indispensabile creare strutture complicate, se non occorre, solo perché è possibile farlo all'occorrenza.

Nel tuo caso, secondo me, ammesso che tu non voglia appoggiarti a framework molto funzionali (es. Entity Framework) e che svolgono egregiamente il lavoro che descrivi, dovresti creare una classe "modello" che rappresenti la tua entità (es. un record della tabella da cui provengono i dati) e creare una classe, o una gerarchia di classi, che forniscano metodi in grado di caricare una singola entità (data la chiave primaria), una lista di entità, oppure di aggiornare, inserire, modificare i dati.

Come strutturarla nello specifico è difficile dirlo: comincia a stendere il codice e quando noti che qualcosa può essere riutilizzato includilo in una classe base condivisa.

In breve, o progetti a priori e completamente il sistema di accesso ai dati che intendi realizzare e scrivi il codice, oppure inizi a scrivere e fattorizzi l'implementazione man mano che aggiungi funzionalità.

Originariamente inviato da luca_gt
Mi pare di capire che sia necessario istanziare una interfaccia per la collection Unit, ma sinceramente non saprei come sia corretto implementare il tutto.

L'uso delle interfacce (se parliamo di interface) non è obbligatorio, ma è consigliato.


Affrontare la questione in termini così generici è impossibile, presupponendo che questa struttura debba farla tu.

L'unica cosa che posso suggerire se hai dubbi generali è "documentati"; per dubbi specifici, ma che siano meno teorici di quelli posti, riporta il codice e vediamo.

Ciao!

[Il Totem]

Se vuoi fare una classe generale, puoi farlo. Basta che incapsuli il comportamento del codice che hai postato in una classe (magari astratta) che implementa le funzionalità base di connessione con un database.
Ad esempio, potresti rappresentare tutti gli attributi con un dizionario: le query verrebbero costruite basandosi sul dizionario di attributi piuttosto che sulle proprietà della classe. Potresti inoltre scrivere una funzione generica che, usando la reflection, inizializzi un qualsiasi tipo di oggetto partendo da una query:

public static IEnumerable<T> GetResultObjects<T>(String query) where T : new
{
    List<Dictionary<String, Object>> queryResults = ExecuteQuery(query);

    foreach(Dictionary<String, Object> record in queryResults)
    {
        T result = new T();
        foreach(PropertyInfo property in typeof(T).GetProperties())
           if (property.CanWrite && queryResult.ContainsKey(property.Name))
              property.SetValue(result, Convert.ChangeType(queryResult[property.Name], property.PropertyType);
        yield return result;
    }
}

Tuttavia la reflection non è il massimo per le prestazioni... (né tanto meno forzare tutte quelle conversioni da Object).

[luca_gt]

Ciao Il Totem,

grazie per il supporto ed il tempo dedicato.

Ciao, Luca