Data Access Objects vecchio stile? [chiuso]

-1

Un paio di settimane fa ho consegnato un lavoro per un progetto universitario. Dopo una revisione del codice con alcuni insegnanti ho avuto alcune osservazioni sul fatto che stavo (ancora) usando gli oggetti di accesso ai dati. L'insegnante in questione che ha detto questo menziona l'uso di DAO nelle sue classi e dice sempre qualcosa sulla falsariga di "Allora abbiamo sempre usato DAO". È un grande fan di Object Relational Mapping, che ritengo sia anche un ottimo strumento. Quando stavo parlando di questo con alcuni dei miei compagni, hanno anche detto che preferiscono l'uso di ORM, che posso capire.

Mi ha fatto però meravigliare, sta usando DAO davvero così vecchio stile? So che al mio lavoro i DAO sono ancora in uso, ma questo è dovuto al fatto che parte del codice è piuttosto vecchia e quindi non può essere accoppiata con ORM. Usiamo anche ORM al mio lavoro.

Il tentativo di trovare ulteriori informazioni su Google o sui siti Stack Exchange non mi ha davvero illuminato.

Devo abbandonare l'utilizzo di DAO e iniziare a implementare ORM? Sento che gli ORM possono essere un po 'esagerati per alcuni progetti semplici. Mi piacerebbe sentire le tue opinioni (o fatti) su questo.

    
posta Bono 19.08.2014 - 15:28
fonte

2 risposte

4

È più "alla moda", ma ciò non significa che non sia più funzionale. Ci sono alcuni sviluppatori che hanno interagito solo con l'archiviazione dei dati usando un ORM.

Determina perché pensi che un ORM sia "over-kill" per un progetto semplice. Fai qualche ricerca e scopri perché sono stati creati. Rende più semplici le attività più grandi o più complesse o semplifica le attività di base / ripetitive / banali? Richiede l'inclusione di più codice di cui non hai veramente bisogno? Richiede più linee di codice o oscura quello che sta succedendo davvero tanto da non poterlo scovare? Potresti scoprire che le tue abilità impostate con un metodo sono più fluenti di altre.

Penso che il codice di formattazione sia simile. Una volta acquisito familiarità e fluidità con qualcosa (ad es. Indentazione del codice) diventa più difficile non farlo. Lavorare con il codice legacy può a volte ostacolare l'acquisizione di fluidità con le nuove tecnologie.

    
risposta data 19.08.2014 - 15:57
fonte
1

Penso che dipenda dal progetto. Entrambi hanno il loro posto.

I DAO ti daranno un maggiore livello di controllo e possono fare cose che un ORM non può fare. I TVF in MS SQL Server, ad esempio, non sono disponibili in EF. Se è necessario lavorare su più database in una stored procedure, ciò non può essere fatto in modo pulito in EF. Quindi per il controllo a basso livello del tuo T-SQL, i DAO hanno il loro posto.

D'altra parte, per l'accesso ai dati di base / diretto utilizzerei un ORM. È meno dispendioso in termini di tempo per farlo, quindi meno costi per il mio cliente. Mostra inoltre lo schema e le relazioni del database in modo semplice e intuitivo. Questo riduce al minimo il tempo per gli altri sviluppatori di riprendere il progetto e capirlo

    
risposta data 19.08.2014 - 16:04
fonte

Leggi altre domande sui tag