Strutture dati orientate agli oggetti in applicazioni basate su database

2

Ho iniziato a lavorare per un'azienda che gestisce un sito web commerciale di piccole / medie dimensioni. Il sito Web è scritto in c # asp.net e utilizza SQL Server come database. La struttura del codice è molto caotica al momento (per esempio ~ 5000 line Utility.cs file) quindi voglio passare a un design migliore sul lato asp.net dell'applicazione.

Sto cercando di capire il modo giusto per farlo. Il mio piano di base è creare una classe per ogni elemento logicamente distinto nell'applicazione (principalmente mappando 1-1 alle tabelle del database, ma a volte N-1 o 1-N). Quindi, ho intenzione di avere alcuni metodi di factory statici per istanziare queste classi interrogando il database. Lo sviluppatore dovrebbe essere in grado di manipolare l'oggetto risultante e quindi utilizzare un metodo UpdateDatabase() per salvare le modifiche al database.

Ad esempio, ecco come funzionerebbe un oggetto Email :

public class Email {
    Guid userId;
    Guid emailId;
    String emailValueInitial = null;
    Sting emailValueNew = null;

    private Email();

    public static Email RetrieveEmail(Guid UserId, Guid EmailId) {
        // .. query
        return new Email(UserId,EmailId,emailValueInitial);            
    }

    public String EmailValue { 
        get {
            if (emailValueNew == null) return emailValueInitial;
            else return emailValueNew;             
        }
        set {
            emailValueNew = value;
        }
    }

    public bool Update() {
       // .. update database with value of emailValueNew or do nothing if it hasn't 
       // been changed
    }

}

Note:

  • Potrei aggiornare il database ogni volta che viene modificato un campo, ma questo è ovviamente inefficiente.
  • Non so cosa fare nel caso in cui lo sviluppatore voglia inserire un valore null nel database - suppongo di aver bisogno di concetti diversi per 'null come variabile non ancora utilizzata' vs 'null come valore del database null'.

Quanto sopra è un caso semplice. Avrei anche bisogno di un modo per conoscere molte relazioni nelle tabelle. Ad esempio, un utente potrebbe lavorare in questo modo:

public class User {
    Guid userId;

    public Emails emails = new Emails(userId);

    private User(); // etc..

    public RetrieveUser();
    public CreateUser();

    public Update();
}

public class Emails {
    List<Email> emails = new List<Email>();

    Guid userId;

    public Emails(Guid userId); // etc..

    public bool CreateEmail(); // its convinient to create/delete from here
    public bool DeleteEmail(); // as I can enforce, say, minimum 1 email per user
}

Questi sono i miei primi pensieri su come risolvere questo problema, ma non ho mai fatto nulla di simile prima, e non so quali problemi potrei incontrare. Voglio creare un sistema che sia scalabile e facile da sviluppare man mano che assumiamo più programmatori, quindi è davvero importante per ottenere il progetto iniziale corretto.

Che tipo di design dovrei usare in un linguaggio orientato agli oggetti per rappresentare e collegare al meglio un database? Quali sono le cose importanti da considerare? C'è letteratura esistente su questo argomento, o importanti librerie / costrutti che ho trascurato?

    
posta Oliver 23.02.2012 - 12:08
fonte

1 risposta

4

Suggerirei di dare un'occhiata seria alle soluzioni ORM come framework di entità e nhibernate .

Quindi suggerirei di elaborare una visione di dove vuoi che l'architettura si sposti nel tempo. attaccalo al muro e dì a tutti gli sviluppatori. Prendi il loro feedback e miglioralo. E assicurati che ogni sviluppatore acquisti la visione.

Quindi, per avanzare verso la visione, adotterei un approccio iterativo e basato sui test per portare diverse parti del sistema sotto esame e migliorarlo gradualmente verso la visione. Per ulteriori informazioni su come avvicinarsi a questa parte, leggi Michael Feahters Lavorare efficacemente con il codice legacy .

    
risposta data 23.02.2012 - 12:38
fonte

Leggi altre domande sui tag