Relazioni SQL profonde con un modello di oggetto C #

Question

Relazioni SQL profonde con un modello di oggetto C #

#1 da (2 voti)
#2 da (1 voti)

4

Ho un database con le relazioni deep table to table

ad esempio

Clients (one to many) -> ClientData (one to many) -> ClientJob (one to many) -> ClientProcess (one to many) -> ClientStep... così via.

E neanche questi sono alberi di rami. Quindi i clienti hanno anche una relazione uno a molti con un altro albero di tabelle. Il database ha un numero molto elevato di tabelle e una serie di relazioni tra di loro.

I modelli C # che ho sono simili nella progettazione a questo

public class Client {

   //base client data
   public string ClientId { get; set; }

   public string ClientName { get; set; }
   //etc...

   //Objects with the one to many relationship
   public List<ClientData> {get; set;}

   public List<ClientLocation> {get; set;}

   //etc..
}

E l'oggetto ClientData ha i suoi dati di base e gli elenchi di oggetti rappresentativi delle sue relazioni con i database relazionali e così via.

Sono stato indirizzato a non utilizzare Entity Framework e invece devo creare viste scritte a mano o stored procedure per l'accesso ai dati.

La mia domanda è, c'è un modello di progettazione che posso utilizzare qui che rende questa struttura SQL / C # efficiente e manutenibile?

Vorrei poter eseguire query su sottostrutture, quindi, anziché ottenere sempre un client completo e tutti gli oggetti correlati, posso ottenere uno specifico ClientData e tutti gli oggetti nidificati ma non il client che lo possiede.

c# sql design-patterns

posta tt9 07.10.2015 - 19:37

fonte

2 risposte

2

È qui che una libreria relazionale / di mappatura degli oggetti, come NHibernate o Entity Framework, è utile. Gestisce l'SQL, il caricamento e la mappatura pigri per te.

Avere una struttura profonda di tabelle interconnesse non è una cattiva idea. La corretta progettazione dei dati e la normalizzazione possono dettare la necessità di queste relazioni. Gli OR / M cercano di colmare il divario tra un modello di dati relazionale e uno orientato agli oggetti per rendere più facile fare esattamente ciò che stai trovando difficile.

I have been directed to not use Entity Framework, and instead I must create hand written views or stored procedures for data access.

È ancora possibile chiamare stored procedure per il recupero dei dati, inserimenti, aggiornamenti ed eliminazioni tramite NHibernate. Nonostante ciò che ti è stato detto, un OR / M ti farà risparmiare mal di testa. La struttura e le relazioni della tua tabella sono abbastanza complesse per trarne vantaggio.

risposta data 07.10.2015 - 22:41

fonte

Leggi altre domande sui tag c# sql design-patterns

Cosa succederebbe se due diversi commit in un repository git avessero lo stesso hash? Verifica in quale regione è presente un indicatore di posizione

score 1 · Accepted Answer

Sembra che qualcuno voglia scrivere un sacco di SQL.

Sto assumendo qui solo la lettura dei dati poiché questa è una domanda specifica.

In passato, ho creato un componente AutoMapper -like che mappava un DataRow a una classe esaminando i nomi delle proprietà della classe con la riflessione , quindi assegna colonne di DataTable corrispondenti con lo stesso nome e tipo simile alle proprietà della classe.

Quindi, basandoci solo su un po ', puoi convertire un intero DataTable in un elenco di oggetti. Credo che AutoMapper lo farà già .

La query per popolare un'intera struttura ad oggetti di solito riportava più DataTable nel DataSet.

-- data table 0
SELECT ... FROM Client WHERE ClientId = @clientId;
-- data table 1
SELECT ... FROM ClientData WHERE ClientId = @clientId;
-- data table 2
SELECT b.*
FROM ClientData a
JOIN ClientJob b ON b.ClientDataId = a.ClientDataId
WHERE a.ClientId = @clientId;
-- etc.

Quindi basandoci su questa e con alcune configurazioni iniziali, puoi convertire un intero DataSet in un albero degli oggetti.

var sqlToObjectConfig = new []
{
    typeof(Client),
    typeof(ClientData),
    typeof(ClientJob)
};

// call your converter
ConvertToObject<Client>(sqlToObjectConfig, dataSet);
// it will use the config to know the type of each DataTable (by index)

Quindi i tuoi passaggi normali sarebbero:

Sviluppa una query per ottenere i dati desiderati
Definire una matrice di configurazione per la conversione della query in oggetti
Definisci un metodo per eseguire la query e convertire

Potresti interrogare in modo relativamente semplice un ramo specifico come ClientJob.