La comunicazione tra BLL e DAL

StackOverflow https://stackoverflow.com/questions/3952534

Domanda

configurazione Soluzione:

  • DAL (libreria di classi)
  • BLL (libreria di classi)
  • Comune (libreria di classi (alcune funzionalità comuni - enumerazioni, la registrazione, eccezioni, ...))
  • Application1 (Windows Application)
  • Application2 (Windows Application)
  • WebApp (applicazione Web)
  • ...

Diciamo che ho un Clienti entità, che è:

  • una tabella in SQL Server
  • un CustomerDataTable in DAL
  • una classe Customer nel BLL
  • una classe BLL.Customer in tutte le applicazioni

Che tipo di oggetti dovrebbe BLL e DAL utilizzare per la comunicazione - DataTable o List<Customer> (per esempio)? Nel primo caso, la logica BLL dovrebbe oggetto di trasformazione Cliente di DataTable e inviarlo a DAL. Nel caso in cui secondo articolo, strato DAL dovrebbe essere a conoscenza di classe Customer, che è in layer BLL. Ma i riferimenti DLL originaly DAL e non contrario ...

Devo inserire tutte le classi in assemblea separata, cui si fa riferimento per tutti gli altri (comuni, BusinessObjects, ...)? In questo caso ho potuto utilizzare classe Cliente in tutti i miei progetti.

Dovrei nemmeno la briga di DAL separato e BLL quando so, che un solo BLL userà il mio DAL. In questo caso ho potuto fondersi insieme in un unico progetto.

PS - Sto leggendo su DataTable e un sacco di gente dice che non dovremmo usare affatto. Quali sono le opzioni migliori? Forse è giunto il momento per me di imparare alcuni strumenti di mappatura ORM:)

È stato utile?

Soluzione

A mio parere si dovrebbe avere un altro strato (DLL separata). Come "dominio", dove si sarebbe mantenere tutte le entità come clienti. Poi basta inserire in tutti i livelli più alti (DAL, BLL, interfaccia utente e altri) in gerarchia di questa assemblea.

Architettura campione può assomigliare a questo:

(Database) <-> DAL <-> BL <-> UI

e a tutti i livelli si avrà accesso al livello di "dominio". DAL deve restituire elenco non un DataTable. Su un certo punto il processo di sviluppo si consiglia di utilizzare in qualche DAL OMR come NHibernate con sarebbe anche restituire un elenco, probabilmente.

Altri suggerimenti

è difficile rispondere a questa domanda di carattere generale senza conoscere il dominio di applicazione abbastanza bene. Vorrei iniziare con il pensiero di dove i futuri cambiamenti sono più probabili e cercare di capire da quello in cui è richiesta flessibilità.

il mio pensiero seguente è solo un suggerimento. sentitevi liberi di considerarli e cambiamento / ignorare ciò che si sente è irrilevante.

che separa il DAL dalla BLL è quasi sempre una buona idea. lo schema dei dati è una cosa che dovrebbe essere incapsulato e nascosto dal resto dell'applicazione, in modo da lasciare i vostri DataTable, DataSet, ORM o qualsiasi altra soluzione nascosto nel DAL. BLL (e gli strati sovrastanti) dovrebbero utilizzare tipi di dati semplici (cioè semplici classi). Penso che sarebbe una buona idea mettere le classi in una libreria di classi modello che non ha riferimenti e può essere utilizzato in tutto il mondo.

ci si sente come avete un po 'troppo stratificazione ... non si ha realmente bisogno di una classe Customer nel BLL e un altro nel livello di applicazione? potrebbe essere, ma vorrei fare in modo e penso che due volte.

dalla mia esperienza in uno dei miei recente progetto (un sito web tempo con 200K di visitatori unici al giorno), abbiamo usato link2sql per l'accesso ai dati (per lo più sola lettura dei dati), e classi di dati semplici in tutto la nostra applicazione ASP.Net MVC ( naturalmente, come parte di modelli / visualizzare i modelli). ha funzionato senza intoppi, e abbiamo potuto facilmente modificare la combinazione di dati senza abbattere gli altri livelli.

Per quanto riguarda la tua ultima domanda sulla DataTable, questi oggetti, se dovessi decidere di usarli (vorrei votare contro), appartengono esclusivamente nella vostra DAL. essi non devono essere esposti ad altri strati come che creerebbe accoppiamento a tale classe specifica. cosa succede se MS domani inventa una classe molto migliore? vuoi passare ora che avete un trilione di riferimento in tutto i vostri progetti per il DataTable, il suo metodo e le proprietà? sarebbe bello cambiare solo il tuo DAL al lavoro con la classe NewAwsomeDataTable e il resto della tua app è beatamente ignorante.

speranza che ha aiutato:)

Vorrei utilizzare il seguente modello in quanto consente di effettuare l'aggiornamento a una strategia di persistenza diversa in seguito. 

UI/Consumer  <--- (view models) --> BLL <--- Models ----> DAL/Persistence

Ecco i modelli View sono consumati al di fuori della BLL e modelli sono comunicati attraverso i / strati DAL BLL.

Nel tuo caso il modello può essere qualsiasi cosa gli utilizzi DAL - DataTable ad esempio o enti in seguito forse ORM. Il BLL è responsabile per la mappatura tra il modello modello e la vista.

Per quanto riguarda i tipi mantenere nelle loro assemblee - sì per i modelli vista e al fine di mantenere una consistenza, sì per i modelli pure.

Mantenere i modelli e visualizzare i modelli separati fermate fuoriuscita delle strategie di persistenza al di fuori della BLL e consente quindi modifiche di impostazione future per la persistenza.

Un vantaggio di questa separazione è che che diversi consumatori vista del modello possono avere differenti modelli vista per lo stesso modello di persistenza / entità. Alcuni potrebbero essere piccoli e hanno pochi attributi e altri grandi e ricchi di funzionalità. Essa consente inoltre di introdurre offline / capacità di sconnessione come i modelli vista potrebbero essere restituiti in tempi diversi che consente di decidere la fusione di dati strategie. Ciò consente anche sei entità di persistenza (ad esempio tavoli di crescere e di forma il cambiamento). Dal momento che questo sembra un .net cose implementazione come il automapper fornirà un sacco di funzionalità out of the box

Naturalmente questo può essere il modo eccessivo per la vostra applicazione - tuttavia mi piacerebbe ancora mantenere una mappatura BLL che parla solo visualizzare i modelli per tutti i consumatori BLL. Questo dovrebbe dare sufficiente disaccoppiamento.

Spingendo le entità del dominio in dal è un'opzione che permetterebbe di eliminare la dipendenza crcular, ma potrebbe non corrispondere il vostro intento. Questo non è inaudito, però; ad esempio LINQ to SQL gnerated entità avrebbero vissuto nel DAL.

Altre opzioni:

  • li ha messi in un comune BASSA di montaggio (ma che può lasciare il vostro BL piuttosto vuota)
  • utilizzare IOC rimuovere / invertire il riferimento fra BL / DAL

Non ci sono singole risposte giuste qui.

Re DataTable; Personalmente sono d'accordo - io non sono un fan;) Tuttavia, possono essere utilizzati con successo e ragionevolmente. Ma se had di usarli, mi piacerebbe loro di essere tenevo nel DAL come un dettaglio di implementazione -. E non esporli al di sopra che

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top