Principi di progettazione - conformità dei dati / logica aziendale nel livello di accesso ai dati?

Naviga le tue risposte
1

Sto lavorando su un piccolo progetto di webservice (java, axis2 ..). Esiste un sacco di codice esistente, il codice è diviso in molti livelli, dal primo livello in cui la richiesta viene interpretata in pochi livelli fino al livello dao. Nel livello dao vedo un codice di convalida intervallato in alcuni punti. Il progetto contiene tabelle che hanno più colonne univoche, quindi l'utente può inserire una singola colonna o una combinazione di colonne. La validazione in livello dao serve a verificare se esiste una combinazione di questo tipo, se non lanciare un'eccezione.

Mi è stato detto che questo tipo di controlli sono più legati allo schema e quindi devono essere nel livello dao. L'interfaccia dao ha metodi come "checkIfThisExists / checkComboExists", sarebbe un progetto "corretto"? Ho sempre pensato che il lavoro dao dovesse essere solo quello di inviare e ricevere dati, più come ottenere e impostare.

    
posta Rnet 18.07.2011 - 19:53
fonte

3 risposte

2

Penso che i DAO siano per la persistenza. Se volessi garantire l'integrità a livello di database, lo farei nel database stesso, ma la convalida e il binding dovrebbero essere completati molto prima che i dati raggiungessero il DAO.

Una richiesta in arrivo al tuo servizio web deve essere convalidata e vincolata quando raggiunge il servizio web.

    
risposta data 18.07.2011 - 19:56
fonte
1

Di solito vado per questa architettura, è molto standard e mi ha servito molte volte:

  • Una libreria comune con POCO e interfacce definite.
  • Un livello di accesso ai dati basato su un'interfaccia comune in modo che sia intercambiabile. Associerà le tabelle del database al POCO.
  • Un livello aziendale che richiede l'implementazione dell'interfaccia DAL per funzionare e che inietterà le regole aziendali e la convalida su POCO.
  • Come molti livelli di interfaccia utente di cui hai bisogno (web app, servizio web, ecc.) che parleranno solo con il livello aziendale, conosceranno i POCO e forniranno al BLL il DAL appropriato tramite Inversion of Control.

In questo modo hai tutto disaccoppiato, le tue "cose comuni" sono definite in uno spazio dei nomi isolato e hai un singolo core (il livello aziendale) mentre puoi avere più livelli di dati intercambiabili e più applicazioni di interfaccia utente simultanee.

    
risposta data 19.07.2011 - 16:21
fonte
0

Non vedo un problema con questo. Sembra una logica di accesso ai dati, quindi ha senso limitarlo al livello di accesso ai dati. Facendo questo tipo di convalida più in alto richiederebbe un round-trip aggiuntivo al database, che diventerebbe rapidamente costoso (a meno che non si possa memorizzare facilmente le informazioni richieste).

    
risposta data 19.07.2011 - 17:40
fonte

Leggi altre domande sui tag

Filtro degli indirizzi IP sul gruppo di utenti valido: dovremmo includere l'indirizzo IP degli sviluppatori? Libri sullo sviluppo dell'interfaccia iPhone personalizzata? [chiuso]