Ho cominciato a programmare per .net in C# da un po', mi ritrovo a dover fare una cosa un po' strana con le classi:
ho una superclasse Entity in cui definisco i metodi che devono ridefinire le classi figlie e delle proprieta'(costanti) che le classi figlie dovrebbero ridefinire, ad esempio le etichette dei campi , attualmente per risolvere il problema ho definito delle proprieta' nella superclasse che vengono impostate poi nel costruttore della classe figlio, ma e' un metodo sporchissimo. Di seguito un po' di codice per capire meglio il problema:
questa la superclasse astratta
public abstract class Entity
{
  public string[] labels;// etichette dei campi
  public string[] fields;// nomi dei campi 
  public string[] rules;// regole dei campi 
  public abstract bool create(string[] values);
  public abstract bool update(string[] values);
  public abstract bool delete();
  ...
}

e questa la classe figlio
 
public class Utente : Entity
{
  
  private const string table = "Utenti"; //nome della tabella
  public const int _ADMIN = 0;
  public const int _VISORE = 1;
  public const int _UTENTE = 2;
  //public DataSet ds;

  public void Utente(){
  this.labels  = new string[] {"uID","Username","Password"};
  this.fields = new string[] {"uID","utente","pass"};
  this.rules = new string[] {"nv","textbox§30","textbox§20"};
        }
...
}

quindi (spero che) ci dovrebbe essere qualche modo per evitare questo spreco di risorse e ridefinire proprieta' costanti (static andrebbero gia' meglio) nelle classi figlie che siano utilizzabili guardandole con il tipo della superclasse.

Grazie in anticipo per qualunque consiglio.
KernelFolla
Premetto che non ho la minima idea riguardo al tipo di progetto che stai sviluppando.
Se posso darti un consiglio, prima di buttar giù del codice, fatti uno schema esaustivo dell'approccio con il quale intendi implementare tutta la Business Logic.

Mi permetto di farti qualche appunto.

1) Non definire costanti in quel modo. Nel caso del ruolo degli utenti, ad esempio, potresti definire un'enumerazione. La tua classe esporrà poi una proprietà il cui tipo corrisponde all'enumerazione sopracitata.

2) Separa le collezioni e gli oggetti custom che le compongono dalla logica di interfacciamento con la base di dati.

3) Lavora con le proprietà quando possibile e lascia tutti i campi che definisci all'interno di una classe privati.

Questo guisto per partire.
Hai partecipato al Real Code Day?
Riccardo ha tirato giù parecchio codice e da esso estrapolerai spunti eccellenti.

Ti do il link:
http://www.dotnetcircle.it/firenze05.aspx

Nicola Baldi
"Make things as simple as possible, but not simpler."
>>> My blog <<<
In effetti e' stato buttato tutto dentro delle classi entity per facilitare il lavoro di chi si sta occupando di integrare tutta la logica business, poi mi tocca spostare delle cose in classi controller e le query in un datamapper(si, lavoro in piu' ma questo mi permette di far lavorare anche gli altri), ho dimenticato di dire che il progetto e' per un esame universitario di ingegneria del software, nulla di serio quindi:). Ora mi studio la documentazione del real code day a cui non ho potuto partecipare per ovvi motivi, qualche slide in piu' avrebbe fatto comodo, pazienza.
Tnx a lot per i consigli.
KernelFolla
Modificato da KernelFolla il 05 dicembre 2005 21.53 -
KernelFolla ha scritto:
...qualche slide in piu' avrebbe fatto comodo...


Slide?!
Sei pazzo! Non farti sentire da Mister Bochicchio!

Nicola Baldi
"Make things as simple as possible, but not simpler."
>>> My blog <<<

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.