È meglio creare classi del modello o bastone con classe di utilità del database generico?

Question

Abbiamo una semplice classe di utilità interna alle nostre chiamate di database (un involucro leggero attorno a ADO.NET), ma sto pensando di creare classi per ogni database/oggetto. Sarebbe una cosa intelligente farlo, o sarebbe utile solo se stessimo usando il framework MVC completo per ASP.NET?

Quindi abbiamo questa:

SQLWrapper.GetRecordset(connstr-alias, sql-statement, parameters); 
SQLWrapper.GetDataset(connstr-alias, sql-statement, parameters); 
SQLWrapper.Execute(connstr-alias, sql-statement, parameters); 

Pensando di fare questo:

Person p = Person.get(id); 
p.fname = "jon"; 
p.lname = "smith"; 
p.Save(); 

o per un nuovo record -

Person p = new Person(); 
p.fname = "Jon"; 
p.lname = "Smith"; 
p.Save(); 
p.Delete(); 

questo sarebbe intelligente, o sarebbe eccessivo? Riesco a vedere i vantaggi per il riutilizzo, la modifica del database e la manutenzione/leggibilità.

Answer 1

Questa domanda viene caricata, progettazione basata sui dati e progettazione basata sul dominio. Per qualsiasi applicazione che abbia una buona quantità di comportamento, è preferibile la progettazione basata sul dominio. Le segnalazioni o le applicazioni di utilità tendono a funzionare meglio (o sono più veloci da sviluppare) con la progettazione guidata dai dati.

Quello che chiedi è "la mia azienda dovrebbe cambiare radicalmente il modo in cui progettiamo il nostro codice". Come un mostro del dominio, la mia reazione istintiva è di gridare sì. Tuttavia, per la natura semplice della tua domanda, non sono sicuro di comprendere appieno la portata del cambiamento che stai proponendo. Penso che dovresti parlarne di più con il tuo team.

ottenere alcuni la letteratura, come ad esempio Evan's DDD libro, o il free foundations ebook, e quindi vi troverete in una posizione migliore per giudicare quale direzione si dovrebbe andare.

Answer 2

In nessun modo MVC è l'unico modello di progettazione per il Web, ma è utile.

Adottare solo la 'M' pagherà dividendi, a mio parere, anche se non è possibile/non adotterà la 'V' o 'C'.

Answer 3

Per me sembra che tu stia cercando di fare ciò che LINQ può già fare per te. Se sei bloccato in un vecchio framework in cui non puoi utilizzarlo, potrei suggerirti di usare Subconic (http://subsonicproject.com/) invece di dover creare manualmente tutti questi oggetti del modello a mano.

Avevo un progetto in cui mi trovavo in una situazione analoga e sono passato a metà subsonico con risultati fantastici. Sviluppo più rapido e MOLTO più facile da leggere/utilizzare il codice.

Answer 4

L'approccio che discute è considerato buono da molti, me incluso! Imparare questo approccio richiederà qualche sforzo, ma non lasciatevi scoraggiare!

Che ne dici di provare un piccolo progetto con LINQ su SQL? Forse trova un nice reference project su google code e studia come altri hanno lavorato con esso.

È uno strumento semplice e consente di acquisire familiarità con alcuni dei problemi relativi alla mappatura degli oggetti nei database.

Si sarà quindi in grado di provare e decidere se vale la curva di apprendimento.

Ci saranno nuovi concetti da afferrare e sperimentare, cose come:

• unità di lavoro: Quando si esegue salvare ed eliminare ecc, un ORM tende a non farlo subito, mentre un DAL basato su recordset. Questo può essere sorprendente, quindi dovrai imparare un po 'su questo. Leggi il modello Unità di lavoro per capire questo.
• Operazioni di blocco sono un problema con OR/M. Un lettore di dati può iterare in modo efficiente attraverso migliaia di righe, ma con un ORM è necessario fare attenzione quando si lavora con grandi lotti di oggetti. Di nuovo, uno su cui leggere.
• Le associazioni sembrano grandi quando possono fare cose come customer.Orders.Count ma sono anche la causa di molti problemi. Avrai bisogno di trovare alcune pratiche sicure da seguire quando lavori con le associazioni.

... solo per citarne alcuni.

Per i principianti, non preoccuparti dell'ereditarietà e delle cose, basta iniziare in modo semplice e disporre di entità semplici che si associano alle tabelle.

Provare a utilizzarli nello stesso modo in cui si utilizza il DAL esistente. Quindi inizia a sperimentare con le associazioni.

Allora forse prova a mettere più comportamenti nelle tue entità. Se inizi a piacergli e ritieni di aver bisogno di più funzionalità, prova a provare un ORM ricco di funzionalità come Lightspeed o NHibernate.

Spero che questo aiuti!